Skip to content
Commits on Apr 18, 2009
  1. @gitster

    Merge branch 'lt/pack-object-memuse'

    gitster committed Apr 18, 2009
    * lt/pack-object-memuse:
      show_object(): push path_name() call further down
      process_{tree,blob}: show objects without buffering
Commits on Apr 13, 2009
  1. @torvalds @gitster

    show_object(): push path_name() call further down

    torvalds committed with gitster Apr 10, 2009
    In particular, pushing the "path_name()" call _into_ the show() function
    would seem to allow
     - more clarity into who "owns" the name (ie now when we free the name in
       the show_object callback, it's because we generated it ourselves by
       calling path_name())
     - not calling path_name() at all, either because we don't care about the
       name in the first place, or because we are actually happy walking the
       linked list of "struct name_path *" and the last component.
    Now, I didn't do that latter optimization, because it would require some
    more coding, but especially looking at "builtin-pack-objects.c", we really
    don't even want the whole pathname, we really would be better off with the
    list of path components.
    Why? We use that name for two things:
     - add_preferred_base_object(), which actually _wants_ to traverse the
       path, and now does it by looking for '/' characters!
     - for 'name_hash()', which only cares about the last 16 characters of a
       name, so again, generating the full name seems to be just unnecessary
    Anyway, so I didn't look any closer at those things, but it did convince
    me that the "show_object()" calling convention was crazy, and we're
    actually better off doing _less_ in list-objects.c, and giving people
    access to the internal data structures so that they can decide whether
    they want to generate a path-name or not.
    This patch does that, and then for people who did use the name (even if
    they might do something more clever in the future), it just does the
    straightforward "name = path_name(path, component); .. free(name);" thing.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  2. @torvalds @gitster

    process_{tree,blob}: show objects without buffering

    torvalds committed with gitster Apr 10, 2009
    Here's a less trivial thing, and slightly more dubious one.
    I was looking at that "struct object_array objects", and wondering why we
    do that. I have honestly totally forgotten. Why not just call the "show()"
    function as we encounter the objects? Rather than add the objects to the
    object_array, and then at the very end going through the array and doing a
    'show' on all, just do things more incrementally.
    Now, there are possible downsides to this:
     - the "buffer using object_array" _can_ in theory result in at least
       better I-cache usage (two tight loops rather than one more spread out
       one). I don't think this is a real issue, but in theory..
     - this _does_ change the order of the objects printed. Instead of doing a
       "process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
       over the commits (which puts all the root trees _first_ in the object
       list, this patch just adds them to the list of pending objects, and
       then we'll traverse them in that order (and thus show each root tree
       object together with the objects we discover under it)
       I _think_ the new ordering actually makes more sense, but the object
       ordering is actually a subtle thing when it comes to packing
       efficiency, so any change in order is going to have implications for
       packing. Good or bad, I dunno.
     - There may be some reason why we did it that odd way with the object
       array, that I have simply forgotten.
    Anyway, now that we don't buffer up the objects before showing them
    that may actually result in lower memory usage during that whole
    traverse_commit_list() phase.
    This is seriously not very deeply tested. It makes sense to me, it seems
    to pass all the tests, it looks ok, but...
    Does anybody remember why we did that "object_array" thing? It used to be
    an "object_list" a long long time ago, but got changed into the array due
    to better memory usage patterns (those linked lists of obejcts are
    horrible from a memory allocation standpoint). But I wonder why we didn't
    do this back then. Maybe there's a reason for it.
    Or maybe there _used_ to be a reason, and no longer is.
    Signed-off-by: Junio C Hamano <>
Commits on Apr 8, 2009
  1. @chriscool @gitster

    list-objects: add "void *data" parameter to show functions

    chriscool committed with gitster Apr 6, 2009
    The goal of this patch is to get rid of the "static struct rev_info
    revs" static variable in "builtin-rev-list.c".
    To do that, we need to pass the revs to the "show_commit" function
    in "builtin-rev-list.c" and this in turn means that the
    "traverse_commit_list" function in "list-objects.c" must be passed
    functions pointers to functions with 2 parameters instead of one.
    So we have to change all the callers and all the functions passed
    to "traverse_commit_list".
    Anyway this makes the code more clean and more generic, so it
    should be a good thing in the long run.
    Signed-off-by: Christian Couder <>
    Signed-off-by: Junio C Hamano <>
Commits on Sep 7, 2006
  1. pack-objects: further work on internal rev-list logic.

    Junio C Hamano committed Sep 6, 2006
    This teaches the internal rev-list logic to understand options
    that are needed for pack handling: --all, --unpacked, and --thin.
    It also moves two functions from builtin-rev-list to list-objects
    so that the two programs can share more code.
    Signed-off-by: Junio C Hamano <>
  2. Separate object listing routines out of rev-list

    Junio C Hamano committed Sep 4, 2006
    Create a separate file, list-objects.c, and move object listing
    routines from rev-list to it.  The next round will use it in
    pack-objects directly.
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.