• J
    traverse_commit_list: support pending blobs/trees with paths · 20739490
    Jeff King 提交于
    When we call traverse_commit_list, we may have trees and
    blobs in the pending array. As we process these, we pass the
    "name" field from the pending entry as the path of the
    object within the tree (which then becomes the root path if
    we recurse into subtrees).
    
    When we set up the traversal in prepare_revision_walk,
    though, the "name" field of any pending trees and blobs is
    likely to be the ref at which we found the object. We would
    not want to make this part of the path (e.g., doing so would
    make "git rev-list --objects v2.6.11-tree" in linux.git show
    paths like "v2.6.11-tree/Makefile", which is nonsensical).
    Therefore prepare_revision_walk sets the name field of each
    pending tree and blobs to the empty string.
    
    However, this leaves no room for a caller who does know the
    correct path of a pending object to propagate that
    information to the revision walker. We can fix this by
    making two related changes:
    
      1. Use the "path" field as the path instead of the "name"
         field in traverse_commit_list. If the path is not set,
         default to "" (which is what we always ended up with in
         the current code, because of prepare_revision_walk).
    
      2. In prepare_revision_walk, make a complete copy of the
         entry. This makes the path field available to the
         walker (if there is one), solving our problem.
         Leaving the name field intact is now OK, as we do not
         use it as a path due to point (1) above (and we can use
         it to make more meaningful error messages if we want).
         We also make the original "mode" field available to the
         walker, though it does not actually use it.
    
    Note that we still re-add the pending objects and free the
    old ones (so we may strdup the path and name only to free
    the old ones). This could be made more efficient by simply
    copying the object_array entries that we are keeping.
    However, that would require more restructuring of the code,
    and is not done here.
    Signed-off-by: NJeff King <peff@peff.net>
    Signed-off-by: NJunio C Hamano <gitster@pobox.com>
    20739490
list-objects.c 6.0 KB