This project is mirrored from https://github.com/git/git. Updated .
  1. 15 Sep, 2014 1 commit
    • Junio C Hamano's avatar
      gpg-interface: move parse_signature() to where it should be · d7c67668
      Junio C Hamano authored
      Our signed-tag objects set the standard format used by Git to store
      GPG-signed payload (i.e. the payload followed by its detached
      signature) [*1*], and it made sense to have a helper to find the
      boundary between the payload and its signature in tag.c back then.
      
      Newer code added later to parse other kinds of objects that learned
      to use the same format to store GPG-signed payload (e.g. signed
      commits), however, kept using the helper from the same location.
      
      Move it to gpg-interface; the helper is no longer about signed tag,
      but it is how our code and data interact with GPG.
      
      [Reference]
      *1* http://thread.gmane.org/gmane.linux.kernel/297998/focus=1383Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d7c67668
  2. 28 Jul, 2014 2 commits
    • Jeff King's avatar
      add object_as_type helper for casting objects · c4ad00f8
      Jeff King authored
      When we call lookup_commit, lookup_tree, etc, the logic goes
      something like:
      
        1. Look for an existing object struct. If we don't have
           one, allocate and return a new one.
      
        2. Double check that any object we have is the expected
           type (and complain and return NULL otherwise).
      
        3. Convert an object with type OBJ_NONE (from a prior
           call to lookup_unknown_object) to the expected type.
      
      We can encapsulate steps 2 and 3 in a helper function which
      checks whether we have the expected object type, converts
      OBJ_NONE as appropriate, and returns the object.
      
      Not only does this shorten the code, but it also provides
      one central location for converting OBJ_NONE objects into
      objects of other types. Future patches will use that to
      enforce type-specific invariants.
      
      Since this is a refactoring, we would want it to behave
      exactly as the current code. It takes a little reasoning to
      see that this is the case:
      
        - for lookup_{commit,tree,etc} functions, we are just
          pulling steps 2 and 3 into a function that does the same
          thing.
      
        - for the call in peel_object, we currently only do step 3
          (but we want to consolidate it with the others, as
          mentioned above). However, step 2 is a noop here, as the
          surrounding conditional makes sure we have OBJ_NONE
          (which we want to keep to avoid an extraneous call to
          sha1_object_info).
      
        - for the call in lookup_commit_reference_gently, we are
          currently doing step 2 but not step 3. However, step 3
          is a noop here. The object we got will have just come
          from deref_tag, which must have figured out the type for
          each object in order to know when to stop peeling.
          Therefore the type will never be OBJ_NONE.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c4ad00f8
    • Jeff King's avatar
      move setting of object->type to alloc_* functions · fe24d396
      Jeff King authored
      The "struct object" type implements basic object
      polymorphism.  Individual instances are allocated as
      concrete types (or as a union type that can store any
      object), and a "struct object *" can be cast into its real
      type after examining its "type" enum.  This means it is
      dangerous to have a type field that does not match the
      allocation (e.g., setting the type field of a "struct blob"
      to "OBJ_COMMIT" would mean that a reader might read past the
      allocated memory).
      
      In most of the current code this is not a problem; the first
      thing we do after allocating an object is usually to set its
      type field by passing it to create_object. However, the
      virtual commits we create in merge-recursive.c do not ever
      get their type set. This does not seem to have caused
      problems in practice, though (presumably because we always
      pass around a "struct commit" pointer and never even look at
      the type).
      
      We can fix this oversight and also make it harder for future
      code to get it wrong by setting the type directly in the
      object allocation functions.
      
      This will also make it easier to fix problems with commit
      index allocation, as we know that any object allocated by
      alloc_commit_node will meet the invariant that an object
      with an OBJ_COMMIT type field will have a unique index
      number.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      fe24d396
  3. 14 Jul, 2014 2 commits
    • Jeff King's avatar
      add object_as_type helper for casting objects · 8ff226a9
      Jeff King authored
      When we call lookup_commit, lookup_tree, etc, the logic goes
      something like:
      
        1. Look for an existing object struct. If we don't have
           one, allocate and return a new one.
      
        2. Double check that any object we have is the expected
           type (and complain and return NULL otherwise).
      
        3. Convert an object with type OBJ_NONE (from a prior
           call to lookup_unknown_object) to the expected type.
      
      We can encapsulate steps 2 and 3 in a helper function which
      checks whether we have the expected object type, converts
      OBJ_NONE as appropriate, and returns the object.
      
      Not only does this shorten the code, but it also provides
      one central location for converting OBJ_NONE objects into
      objects of other types. Future patches will use that to
      enforce type-specific invariants.
      
      Since this is a refactoring, we would want it to behave
      exactly as the current code. It takes a little reasoning to
      see that this is the case:
      
        - for lookup_{commit,tree,etc} functions, we are just
          pulling steps 2 and 3 into a function that does the same
          thing.
      
        - for the call in peel_object, we currently only do step 3
          (but we want to consolidate it with the others, as
          mentioned above). However, step 2 is a noop here, as the
          surrounding conditional makes sure we have OBJ_NONE
          (which we want to keep to avoid an extraneous call to
          sha1_object_info).
      
        - for the call in lookup_commit_reference_gently, we are
          currently doing step 2 but not step 3. However, step 3
          is a noop here. The object we got will have just come
          from deref_tag, which must have figured out the type for
          each object in order to know when to stop peeling.
          Therefore the type will never be OBJ_NONE.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8ff226a9
    • Jeff King's avatar
      move setting of object->type to alloc_* functions · d36f51c1
      Jeff King authored
      The "struct object" type implements basic object
      polymorphism.  Individual instances are allocated as
      concrete types (or as a union type that can store any
      object), and a "struct object *" can be cast into its real
      type after examining its "type" enum.  This means it is
      dangerous to have a type field that does not match the
      allocation (e.g., setting the type field of a "struct blob"
      to "OBJ_COMMIT" would mean that a reader might read past the
      allocated memory).
      
      In most of the current code this is not a problem; the first
      thing we do after allocating an object is usually to set its
      type field by passing it to create_object. However, the
      virtual commits we create in merge-recursive.c do not ever
      get their type set. This does not seem to have caused
      problems in practice, though (presumably because we always
      pass around a "struct commit" pointer and never even look at
      the type).
      
      We can fix this oversight and also make it harder for future
      code to get it wrong by setting the type directly in the
      object allocation functions.
      
      This will also make it easier to fix problems with commit
      index allocation, as we know that any object allocated by
      alloc_commit_node will meet the invariant that an object
      with an OBJ_COMMIT type field will have a unique index
      number.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d36f51c1
  4. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      functions.
      
      The change can be recreated by mechanically applying this:
      
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
              s|!prefixcmp\(|starts_with\(|g;
              s|prefixcmp\(|!starts_with\(|g;
              s|!suffixcmp\(|ends_with\(|g;
              s|suffixcmp\(|!ends_with\(|g;
            '
      
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      59556548
  5. 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
  6. 05 Nov, 2011 1 commit
    • Junio C Hamano's avatar
      Split GPG interface into its own helper library · 2f47eae2
      Junio C Hamano authored
      This mostly moves existing code from builtin/tag.c (for signing)
      and builtin/verify-tag.c (for verifying) to a new gpg-interface.c
      file to provide a more generic library interface.
      
       - sign_buffer() takes a payload strbuf, a signature strbuf, and a signing
         key, runs "gpg" to produce a detached signature for the payload, and
         appends it to the signature strbuf. The contents of a signed tag that
         concatenates the payload and the detached signature can be produced by
         giving the same strbuf as payload and signature strbuf.
      
       - verify_signed_buffer() takes a payload and a detached signature as
         <ptr, len> pairs, and runs "gpg --verify" to see if the payload matches
         the signature. It can optionally capture the output from GPG to allow
         the callers to pretty-print it in a way more suitable for their
         contexts.
      
      "verify-tag" (aka "tag -v") used to save the whole tag contents as if it
      is a detached signature, and fed gpg the payload part of the tag. It
      relied on gpg to fail when the given tag is not signed but just is
      annotated.  The updated run_gpg_verify() function detects the lack of
      detached signature in the input, and errors out without bothering "gpg".
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2f47eae2
  7. 16 Feb, 2011 1 commit
  8. 07 Feb, 2011 1 commit
  9. 10 Nov, 2010 2 commits
  10. 06 Sep, 2010 1 commit
  11. 13 Apr, 2010 3 commits
  12. 26 Feb, 2008 1 commit
  13. 18 Feb, 2008 1 commit
  14. 07 Jan, 2008 1 commit
  15. 19 Sep, 2007 1 commit
  16. 28 May, 2007 1 commit
  17. 17 Apr, 2007 1 commit
  18. 27 Feb, 2007 2 commits
    • Nicolas Pitre's avatar
      get rid of lookup_object_type() · 0ab17950
      Nicolas Pitre authored
      This function is called only once in the whole source tree.  Let's move
      its code inline instead, which is also in the spirit of removing as much
      object type char arrays as possible (not that this patch does anything for
      that but at least it is now a local matter).
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      0ab17950
    • Nicolas Pitre's avatar
      convert object type handling from a string to a number · 21666f1a
      Nicolas Pitre authored
      We currently have two parallel notation for dealing with object types
      in the code: a string and a numerical value.  One of them is obviously
      redundent, and the most used one requires more stack space and a bunch
      of strcmp() all over the place.
      
      This is an initial step for the removal of the version using a char array
      found in object reading code paths.  The patch is unfortunately large but
      there is no sane way to split it in smaller parts without breaking the
      system.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      21666f1a
  19. 13 Jul, 2006 1 commit
  20. 20 Jun, 2006 2 commits
    • Florian Forster's avatar
      Remove all void-pointer arithmetic. · 1d7f171c
      Florian Forster authored
      ANSI C99 doesn't allow void-pointer arithmetic. This patch fixes this in
      various ways. Usually the strategy that required the least changes was used.
      Signed-off-by: default avatarFlorian Forster <octo@verplant.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      1d7f171c
    • Linus Torvalds's avatar
      Add specialized object allocator · 855419f7
      Linus Torvalds authored
      This creates a simple specialized object allocator for basic
      objects.
      
      This avoids wasting space with malloc overhead (metadata and
      extra alignment), since the specialized allocator knows the
      alignment, and that objects, once allocated, are never freed.
      
      It also allows us to track some basic statistics about object
      allocations. For example, for the mozilla import, it shows
      object usage as follows:
      
           blobs:   627629 (14710 kB)
           trees:  1119035 (34969 kB)
         commits:   196423  (8440 kB)
            tags:     1336    (46 kB)
      
      and the simpler allocator shaves off about 2.5% off the memory
      footprint off a "git-rev-list --all --objects", and is a bit
      faster too.
      
      [ Side note: this concludes the series of "save memory in object storage".
        The thing is, there simply isn't much more to be saved on the objects.
      
        Doing "git-rev-list --all --objects" on the mozilla archive has a final
        total RSS of 131498 pages for me: that's about 513MB. Of that, the
        object overhead is now just 56MB, the rest is going somewhere else (put
        another way: the fact that this patch shaves off 2.5% of the total
        memory overhead, considering that objects are now not much more than 10%
        of the total shows how big the wasted space really was: this makes
        object allocations much more memory- and time-efficient).
      
        I haven't looked at where the rest is, but I suspect the bulk of it is
        just the pack-file loading. It may be that we should pack the tree
        objects separately from the blob objects: for git-rev-list --objects, we
        don't actually ever need to even look at the blobs, but since trees and
        blobs are interspersed in the pack-file, we end up not being dense in
        the tree accesses, so we end up looking at more pages than we strictly
        need to.
      
        So with a 535MB pack-file, it's entirely possible - even likely - that
        most of the remaining RSS is just the mmap of the pack-file itself. We
        don't need to map in _all_ of it, but we do end up mapping a fair
        amount. ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      855419f7
  21. 18 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Shrink "struct object" a bit · 885a86ab
      Linus Torvalds authored
      This shrinks "struct object" by a small amount, by getting rid of the
      "struct type *" pointer and replacing it with a 3-bit bitfield instead.
      
      In addition, we merge the bitfields and the "flags" field, which
      incidentally should also remove a useless 4-byte padding from the object
      when in 64-bit mode.
      
      Now, our "struct object" is still too damn large, but it's now less
      obviously bloated, and of the remaining fields, only the "util" (which is
      not used by most things) is clearly something that should be eventually
      discarded.
      
      This shrinks the "git-rev-list --all" memory use by about 2.5% on the
      kernel archive (and, perhaps more importantly, on the larger mozilla
      archive). That may not sound like much, but I suspect it's more on a
      64-bit platform.
      
      There are other remaining inefficiencies (the parent lists, for example,
      probably have horrible malloc overhead), but this was pretty obvious.
      
      Most of the patch is just changing the comparison of the "type" pointer
      from one of the constant string pointers to the appropriate new TYPE_xxx
      small integer constant.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      885a86ab
  22. 04 Apr, 2006 1 commit
  23. 07 Jan, 2006 1 commit
    • Junio C Hamano's avatar
      [PATCH] Compilation: zero-length array declaration. · 8f1d2e6f
      Junio C Hamano authored
      ISO C99 (and GCC 3.x or later) lets you write a flexible array
      at the end of a structure, like this:
      
      	struct frotz {
      		int xyzzy;
      		char nitfol[]; /* more */
      	};
      
      GCC 2.95 and 2.96 let you to do this with "char nitfol[0]";
      unfortunately this is not allowed by ISO C90.
      
      This declares such construct like this:
      
      	struct frotz {
      		int xyzzy;
      		char nitfol[FLEX_ARRAY]; /* more */
      	};
      
      and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and
      empty for others.
      
      If you are using a C90 C compiler, you should be able
      to override this with CFLAGS=-DFLEX_ARRAY=1 from the
      command line of "make".
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      8f1d2e6f
  24. 17 Nov, 2005 1 commit
  25. 15 Nov, 2005 1 commit
    • Sergey Vlasov's avatar
      Rework object refs tracking to reduce memory usage · 4a4e6fd7
      Sergey Vlasov authored
      Store pointers to referenced objects in a variable sized array instead
      of linked list.  This cuts down memory usage of utilities which use
      object references; e.g., git-fsck-objects --full on the git.git
      repository consumes about 2 MB of memory tracked by Massif instead of
      7 MB before the change.  Object refs are still the biggest consumer of
      memory (57%), but the malloc overhead for a single block instead of a
      linked list is substantially smaller.
      Signed-off-by: default avatarSergey Vlasov <vsu@altlinux.ru>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      4a4e6fd7
  26. 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
  27. 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
  28. 22 Jun, 2005 1 commit
  29. 08 Jun, 2005 1 commit
  30. 20 May, 2005 1 commit
  31. 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
  32. 05 May, 2005 1 commit
  33. 04 May, 2005 1 commit