Two issues in the code confuses any reader of that function.
- The code wants to hash Makefile from different revisions
together, and Makefile and t/Makefile close to each other.
The current code did it by treating '/' specially, used
basename hash as the upper bits of the resulting hash and
dirname hash as the lower bits. It's my tendency to treat
slashes specially too much, which is one of your favorite
things to pick me on.
This is not needed by your change anymore -- by only using
the tail of the filename, and making sure tail part weighs
more in the resulting group number, the new code gives the
desired grouping characteristics in a much simpler way.
- The output from rev-list --objects is fed to the function as
its name parameter while path is set to NULL. When we allow
a thin pack to be generated, rev-list --objects output also
contains "-<commit-object-name>" lines. We read trees for
these commits that are not going to be sent but can be used
as base objects, and pass the pathname discovered from the
tree using path and name pair (path is set to the linked list
of struct name_path that describes the dirname, and name is
set to the basename). This was done to reduce the need for
allocating and copying the pathname in preparation for
calling name_hash() function.
If you use only the "name" variable in your group number
computation, and suppose we are doing send-pack to send
updates between rev A..B, contrib/git-svn/Makefile from rev B
will use git-svn/Makefile (tail 16 characters) to compute the
number, but the blob from rev A (which we are not going to
send but would want to use as a potential delta base) will
have contrib/git-svn part in "path" (the element points at
string "git-svn", and its uplink points at another element
that points at "contrib" with an uplink that says it is at
the root level), and Makefile in "name". They will be hashed
slightly differently.
Junio C Hamano <junkio@cox.net>