Permalink
Commits on Feb 23, 2013
  1. fsync loose objects before moving into place

    peff committed with rtomayko Feb 22, 2013
    When we write a loose object to disk, we simply close the
    file object before moving it into place. If the machine
    crashes shortly after our write, the contents may not have
    been committed to disk (depending your filesystem, usually
    the metadata is, and you end up with a corrupt, zero-length
    loose object file).
    
    This is especially bad because we report that the object is
    successfully written, which means we may have updated refs
    to point to it. A corrupt object at that point means not
    only does the operation fail, but the repository is left in
    a corrupted and unusable state.
    
    We can fix this by calling fsync on the object file before
    linking it into place. Between this and the previous commit,
    our object writing should now behave exactly like git's
    internal routines.
  2. make object writes atomic

    peff committed with rtomayko Feb 22, 2013
    When Grit writes a loose object via the LooseStorage class,
    it just opens the object file and starts writing. This works
    most of the time, but can be a problem in some corner cases,
    including:
    
      1. If another process tries to write the same object
         simultaneously, the writes may be interleaved and the
         object can be corrupted.
    
      2. If another process tries to read the object
         simultaneously, it may see the object in a half-written
         state.
    
      3. If the process or machine crashes during the write, we
         may leave a half-written corrupt object.
    
    This can be solved by writing the object to a temporary file
    and linking it into place. This is the same strategy used by
    git itself.
  3. Missed some stuff

    rtomayko committed Feb 23, 2013
  4. Where github/github actual is

    rtomayko committed Feb 23, 2013
    Pretty clear there's zero fucks for keeping these sync'd up.
  5. Merge pull request #157 from github/atomic-object-writes

    rtomayko committed Feb 23, 2013
    Atomic object writes
Commits on Feb 22, 2013
  1. fsync loose objects before moving into place

    peff committed Feb 22, 2013
    When we write a loose object to disk, we simply close the
    file object before moving it into place. If the machine
    crashes shortly after our write, the contents may not have
    been committed to disk (depending your filesystem, usually
    the metadata is, and you end up with a corrupt, zero-length
    loose object file).
    
    This is especially bad because we report that the object is
    successfully written, which means we may have updated refs
    to point to it. A corrupt object at that point means not
    only does the operation fail, but the repository is left in
    a corrupted and unusable state.
    
    We can fix this by calling fsync on the object file before
    linking it into place. Between this and the previous commit,
    our object writing should now behave exactly like git's
    internal routines.
  2. make object writes atomic

    peff committed Feb 22, 2013
    When Grit writes a loose object via the LooseStorage class,
    it just opens the object file and starts writing. This works
    most of the time, but can be a problem in some corner cases,
    including:
    
      1. If another process tries to write the same object
         simultaneously, the writes may be interleaved and the
         object can be corrupted.
    
      2. If another process tries to read the object
         simultaneously, it may see the object in a half-written
         state.
    
      3. If the process or machine crashes during the write, we
         may leave a half-written corrupt object.
    
    This can be solved by writing the object to a temporary file
    and linking it into place. This is the same strategy used by
    git itself.
Commits on Dec 17, 2012
  1. Merge pull request #149 from shepmaster/patch-1

    holman committed Dec 17, 2012
    Correct spelling of "represent"
Commits on Dec 2, 2012
Commits on Sep 4, 2012
  1. strip newlines from tree entry names

    vmg committed with sbryant Jul 3, 2012
    ported from github.com
  2. Merge pull request #140 from sbryant/fix_rev_parse

    rtomayko committed Sep 4, 2012
    Fix an edge case in rev_parse.
Commits on Sep 2, 2012
  1. Fix an edge case in rev_parse.

    sbryant committed Sep 2, 2012
    Make sure we don't split on a `ref:path' revision.
Commits on Aug 1, 2012
  1. Merge pull request #111 from pda/patch-2

    tmm1 committed Aug 1, 2012
    Minor typo fix in documentation: “buy” → “by”.
Commits on Apr 27, 2012
Commits on Apr 22, 2012
  1. Release 2.5.0

    mojombo committed Apr 22, 2012
  2. Update History.

    mojombo committed Apr 22, 2012
Commits on Jan 27, 2012
  1. git ls-tree raises on non-zero exit

    sr committed Jan 27, 2012
Commits on Dec 29, 2011
  1. Merge pull request #103 from peff/master

    rtomayko committed Dec 29, 2011
    support large packfiles with index v2
Commits on Dec 23, 2011
  1. support large packfiles with index v2

    peff committed Dec 23, 2011
    Grit has known about the "v2" pack index format for a while.
    However, it never actually handled the extended offsets that
    we get when indexing packfiles that are larger than 2
    gigabytes.
    
    When an object is at an offset smaller than 2G, its byte
    offset into the packfile is placed in the first table of
    4-byte offset values. If it's past that, then the MSB is set
    on its offset in the 4-byte table, and the rest of the
    4-byte integer specifies an offset into an 8-byte table that
    follows.
    
    With this patch, grit should handle arbitrarily large packs
    (limited only by the pack format itself).
    
    A few notes on the patch itself:
    
      - I unpack using two "N" formats instead of "Q>", because
        "Q>" is not available in ruby < 1.9.3
    
      - No automated test is included, because you need a
        packfile that is greater than 2G. I did test it by hand.
Commits on Aug 20, 2011
  1. 100% Git-compliant actor creation

    vmg committed Aug 20, 2011
    Some more tweaks here:
    
    	- Do not use `strftime`, because it's not assured
    	to be cross-platform
    
    	- Use C-like string formatting for Great Glory
    	When Printing Numbers.
    
    	- Always print an email address -- even if we don't
    	have one. A missing email field will crash `fsck`.
Commits on Aug 17, 2011
  1. Properly print time offsets

    vmg committed with defunkt Aug 16, 2011
Commits on Jul 10, 2011
  1. handle newlines in author / committer

    rtomayko committed Jul 10, 2011
    This shouldn't technically be allowed but we've seen a few cases of
    it in existing repositories on github.com so let's just deal with
    it.
Commits on Jul 1, 2011
  1. Merge pull request #78 from kevinsawicki/patch-1

    tmm1 committed Jul 1, 2011
    Fix typo in tree method doc
Commits on Jun 22, 2011
  1. Grit::Git check_applies / patch related methods take command hash

    rtomayko committed Jun 22, 2011
    This lets us pass an :env so we can use GIT_ALTERNATE_OBJECT_DIRECTORIES
    to check if a commit applies across repositories.
  2. tags api now resty

    schacon committed with rtomayko Jun 16, 2011
Commits on Jun 15, 2011
  1. ruby rev_list passes --verify to native rev_parse in fallback

    rtomayko committed Jun 15, 2011
    Otherwise, the git-rev-parse will return whatever is given as an arg
    when the ref doesn't exist. e.g.,
    
      $ git rev-parse some-bad-ref
      some-bad-ref
      fatal: ambiguous argument 'some-bad-ref': unknown revision or path not in the working tree.
    
    The error message is on stderr and git-rev-parse exits with non-zero
    but the ref name is still output.
    
    The problem here is that code often calls rev_list like:
    
        git.rev_list({}, "some-bad-ref")
    
    Then rev_list tries to convert some-bad-ref to a SHA1, gets back the
    ref string, but continues on anyway. This eventually results in the
    rev_list failing to look up the object because it assumes its a SHA1
    when its really a ref string.
Commits on Jun 10, 2011
  1. Merge pull request #71 from injekt/master

    rtomayko committed Jun 10, 2011
    Fix warnings on 1.9
  2. Merge pull request #72 from cesario/master

    rtomayko committed Jun 10, 2011
    Fix the gemspec