1. 20 Nov, 2015 3 commits
  2. 19 Oct, 2014 1 commit
  3. 16 Oct, 2014 2 commits
    • Jeff King's avatar
      make add_object_array_with_context interface more sane · 9e0c3c4f
      Jeff King authored
      When you resolve a sha1, you can optionally keep any context
      found during the resolution, including the path and mode of
      a tree entry (e.g., when looking up "HEAD:subdir/file.c").
      
      The add_object_array_with_context function lets you then
      attach that context to an entry in a list. Unfortunately,
      the interface for doing so is horrible. The object_context
      structure is large and most object_array users do not use
      it. Therefore we keep a pointer to the structure to avoid
      burdening other users too much. But that means when we do
      use it that we must allocate the struct ourselves. And the
      struct contains a fixed PATH_MAX-sized buffer, which makes
      this wholly unsuitable for any large arrays.
      
      We can observe that there is only a single user of the
      "with_context" variant: builtin/grep.c. And in that use
      case, the only element we care about is the path. We can
      therefore store only the path as a pointer (the context's
      mode field was redundant with the object_array_entry itself,
      and nobody actually cared about the surrounding tree). This
      still requires a strdup of the pathname, but at least we are
      only consuming the minimum amount of memory for each string.
      
      We can also handle the copying ourselves in
      add_object_array_*, and free it as appropriate in
      object_array_release_entry.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9e0c3c4f
    • Jeff King's avatar
      object_array: add a "clear" function · 46be8231
      Jeff King authored
      There's currently no easy way to free the memory associated
      with an object_array (and in most cases, we simply leak the
      memory in a rev_info's pending array). Let's provide a
      helper to make this easier to handle.
      
      We can make use of it in list-objects.c, which does the same
      thing by hand (but fails to free the "name" field of each
      entry, potentially leaking memory).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      46be8231
  4. 10 Sep, 2014 1 commit
  5. 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
  6. 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
  7. 25 Mar, 2014 2 commits
  8. 28 Feb, 2014 1 commit
  9. 02 Jun, 2013 1 commit
    • Michael Haggerty's avatar
      object_array_entry: fix memory handling of the name field · 31faeb20
      Michael Haggerty authored
      Previously, the memory management of the object_array_entry::name
      field was inconsistent and undocumented.  object_array_entries are
      ultimately created by a single function, add_object_array_with_mode(),
      which has an argument "const char *name".  This function used to
      simply set the name field to reference the string pointed to by the
      name parameter, and nobody on the object_array side ever freed the
      memory.  Thus, it assumed that the memory for the name field would be
      managed by the caller, and that the lifetime of that string would be
      at least as long as the lifetime of the object_array_entry.  But
      callers were inconsistent:
      
      * Some passed pointers to constant strings or argv entries, which was
        OK.
      
      * Some passed pointers to newly-allocated memory, but didn't arrange
        for the memory ever to be freed.
      
      * Some passed the return value of sha1_to_hex(), which is a pointer to
        a statically-allocated buffer that can be overwritten at any time.
      
      * Some passed pointers to refnames that they received from a
        for_each_ref()-type iteration, but the lifetimes of such refnames is
        not guaranteed by the refs API.
      
      Bring consistency to this mess by changing object_array to make its
      own copy for the object_array_entry::name field and free this memory
      when an object_array_entry is deleted from the array.
      
      Many callers were passing the empty string as the name parameter, so
      as a performance optimization, treat the empty string specially.
      Instead of making a copy, store a pointer to a statically-allocated
      empty string to object_array_entry::name.  When deleting such an
      entry, skip the free().
      
      Change the callers that were already passing copies to
      add_object_array_with_mode() to either skip the copy, or (if the
      memory needed to be allocated anyway) freeing the memory itself.
      
      A part of this commit effectively reverts
      
          70d26c6e read_revisions_from_stdin: make copies for handle_revision_arg
      
      because the copying introduced by that commit (which is still
      necessary) is now done at a deeper level.
      Signed-off-by: default avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      31faeb20
  10. 28 May, 2013 2 commits
  11. 10 May, 2013 1 commit
  12. 17 Mar, 2013 1 commit
    • Jeff King's avatar
      avoid segfaults on parse_object failure · 75a95490
      Jeff King authored
      Many call-sites of parse_object assume that they will get a
      non-NULL return value; this is not the case if we encounter
      an error while parsing the object.
      
      This patch adds a wrapper function around parse_object that
      handles dying automatically, and uses it anywhere we
      immediately try to access the return value as a non-NULL
      pointer (i.e., anywhere that we would currently segfault).
      
      This wrapper may also be useful in other places. The most
      obvious one is code like:
      
        o = parse_object(sha1);
        if (!o)
      	  die(...);
      
      However, these should not be mechanically converted to
      parse_object_or_die, as the die message is sometimes
      customized. Later patches can address these sites on a
      case-by-case basis.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      75a95490
  13. 30 Mar, 2012 1 commit
  14. 14 Mar, 2011 1 commit
  15. 30 Aug, 2010 1 commit
  16. 18 Jan, 2010 1 commit
  17. 18 Jan, 2009 1 commit
  18. 10 Sep, 2008 1 commit
  19. 26 Feb, 2008 1 commit
  20. 07 Jun, 2007 1 commit
    • Junio C Hamano's avatar
      War on whitespace · a6080a0a
      Junio C Hamano authored
      This uses "git-apply --whitespace=strip" to fix whitespace errors that have
      crept in to our source files over time.  There are a few files that need
      to have trailing whitespaces (most notably, test vectors).  The results
      still passes the test, and build result in Documentation/ area is unchanged.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a6080a0a
  21. 24 Apr, 2007 1 commit
  22. 17 Apr, 2007 1 commit
  23. 16 Apr, 2007 1 commit
  24. 27 Feb, 2007 3 commits
  25. 16 Sep, 2006 1 commit
  26. 04 Sep, 2006 1 commit
    • Junio C Hamano's avatar
      more lightweight revalidation while reusing deflated stream in packing · 72518e9c
      Junio C Hamano authored
      When copying from an existing pack and when copying from a loose
      object with new style header, the code makes sure that the piece
      we are going to copy out inflates well and inflate() consumes
      the data in full while doing so.
      
      The check to see if the xdelta really apply is quite expensive
      as you described, because you would need to have the image of
      the base object which can be represented as a delta against
      something else.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      72518e9c
  27. 13 Jul, 2006 1 commit
  28. 05 Jul, 2006 1 commit
  29. 03 Jul, 2006 1 commit
  30. 30 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Abstract out accesses to object hash array · fc046a75
      Linus Torvalds authored
      There are a few special places where some programs accessed the object
      hash array directly, which bothered me because I wanted to play with some
      simple re-organizations.
      
      So this patch makes the object hash array data structures all entirely
      local to object.c, and the few users who wanted to look at it now get to
      use a function to query how many object index entries there can be, and to
      actually access the array.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      fc046a75
  31. 20 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Add "named object array" concept · 1f1e895f
      Linus Torvalds authored
      We've had this notion of a "object_list" for a long time, which eventually
      grew a "name" member because some users (notably git-rev-list) wanted to
      name each object as it is generated.
      
      That object_list is great for some things, but it isn't all that wonderful
      for others, and the "name" member is generally not used by everybody.
      
      This patch splits the users of the object_list array up into two: the
      traditional list users, who want the list-like format, and who don't
      actually use or want the name. And another class of users that really used
      the list as an extensible array, and generally wanted to name the objects.
      
      The patch is fairly straightforward, but it's also biggish. Most of it
      really just cleans things up: switching the revision parsing and listing
      over to the array makes things like the builtin-diff usage much simpler
      (we now see exactly how many members the array has, and we don't get the
      objects reversed from the order they were on the command line).
      
      One of the main reasons for doing this at all is that the malloc overhead
      of the simple object list was actually pretty high, and the array is just
      a lot denser. So this patch brings down memory usage by git-rev-list by
      just under 3% (on top of all the other memory use optimizations) on the
      mozilla archive.
      
      It does add more lines than it removes, and more importantly, it adds a
      whole new infrastructure for maintaining lists of objects, but on the
      other hand, the new dynamic array code is pretty obvious. The change to
      builtin-diff-tree.c shows a fairly good example of why an array interface
      is sometimes more natural, and just much simpler for everybody.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      1f1e895f