This project is mirrored from https://github.com/git/git. Updated .
  1. 06 Jan, 2012 1 commit
    • Jeff King's avatar
      upload-pack: avoid parsing tag destinations · 90108a24
      Jeff King authored
      When upload-pack advertises refs, it dereferences any tags
      it sees, and shows the resulting sha1 to the client. It does
      this by calling deref_tag. That function must load and parse
      each tag object to find the sha1 of the tagged object.
      However, it also ends up parsing the tagged object itself,
      which is not strictly necessary for upload-pack's use.
      
      Each tag produces two object loads (assuming it is not a
      recursive tag), when it could get away with only a single
      one. Dropping the second load halves the effort we spend.
      
      The downside is that we are no longer verifying the
      resulting object by loading it. In particular:
      
        1. We never cross-check the "type" field given in the tag
           object with the type of the pointed-to object.  If the
           tag says it points to a tag but doesn't, then we will
           keep peeling and realize the error.  If the tag says it
           points to a non-tag but actually points to a tag, we
           will stop peeling and just advertise the pointed-to
           tag.
      
        2. If we are missing the pointed-to object, we will not
           realize (because we never even look it up in the object
           db).
      
      However, both of these are errors in the object database,
      and both will be detected if a client actually requests the
      broken objects in question. So we are simply pushing the
      verification away from the advertising stage, and down to
      the actual fetching stage.
      
      On my test repo with 120K refs, this drops the time to
      advertise the refs from ~3.2s to ~2.0s.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      90108a24
  2. 07 Feb, 2011 1 commit
  3. 10 Nov, 2010 1 commit
  4. 13 Apr, 2010 2 commits
  5. 03 Nov, 2005 1 commit
    • Junio C Hamano's avatar
      Be careful when dereferencing tags. · 9534f40b
      Junio C Hamano authored
      One caller of deref_tag() was not careful enough to make sure
      what deref_tag() returned was not NULL (i.e. we found a tag
      object that points at an object we do not have).  Fix it, and
      warn about refs that point at such an incomplete tag where
      needed.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      9534f40b
  6. 05 Aug, 2005 1 commit
    • Junio C Hamano's avatar
      Fix send-pack for non-commitish tags. · 37fde874
      Junio C Hamano authored
      Again I left the v2.6.11-tree tag behind.  My bad.
      
      This commit makes sure that we do not barf when pushing a ref
      that is a non-commitish tag.  You can update a remote ref under
      the following conditions:
      
       * You can always use --force.
       * Creating a brand new ref is OK.
       * If the remote ref is exactly the same as what you are
         pushing, it is OK (nothing is pushed).
       * You can replace a commitish with another commitish which is a
         descendant of it, if you can verify the ancestry between them;
         this and the above means you have to have what you are replacing.
       * Otherwise you cannot update; you need to use --force.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      37fde874
  7. 08 Jun, 2005 1 commit
  8. 06 May, 2005 1 commit
    • Nicolas Pitre's avatar
      [PATCH] don't load and decompress objects twice with parse_object() · bd2c39f5
      Nicolas Pitre authored
      It turns out that parse_object() is loading and decompressing given
      object to free it just before calling the specific object parsing
      function which does mmap and decompress the same object again. This
      patch introduces the ability to parse specific objects directly from a
      memory buffer.
      
      Without this patch, running git-fsck-cache on the kernel repositorytake:
      
      	real    0m13.006s
      	user    0m11.421s
      	sys     0m1.218s
      
      With this patch applied:
      
      	real    0m8.060s
      	user    0m7.071s
      	sys     0m0.710s
      
      The performance increase is significant, and this is kind of a
      prerequisite for sane delta object support with fsck.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bd2c39f5
  9. 28 Apr, 2005 2 commits