Junio C Hamano <[EMAIL PROTECTED]> writes:
> Last time I checked, git-http-pull did not utilize the pack
> dependency information, which indeed is wrong. When it decides
> to fetch a pack instead of an asked-for object, it should check
> which commits the pack expects to have in your local repository
> and add them to its list of things to slurp.
Oh, well, the above makes it sound as if I am blaming Daniel for
this, but the blame lies on me who did not document properly
what is going on, in except the comments in the source. So here
is an explanation.
A $GIT_DIR/objects/info/packs file looks like this:
P pack-3c5133604508466855453f3e609428f4bbba9131.pack
P pack-37cba29d3df65b160afabe769470f7857f98d729.pack
D 0
D 1 0
T 0 c1c774e7965ba08061c3fc7bc57aebc7eeb6b40f commit
T 0 d6602ec5194c87b0fc87103ca4d67251c76f233a tag
T 1 0918385dbd9656cab0d1d81ba7453d49bbc16250 tag
T 1 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e tag
T 1 b3e9704ecdf48869f635f0aa99ddfb513f885aff tag
T 1 c5db5456ae3b0873fc659c19fafdde22313cc441 tag
T 1 f25a265a342aed6041ab0cc484224d9ca54b6f41 tag
P lines are list of packs, and they are implicitly numbered
starting from #0. 3c5133 pack is pack #0 and 37cba2 pack is
pack #1 in the above example.
D lines are pack dependencies. "D 0" says pack #0 does not
depend on any, "D 1 0" says pack #1 depends on pack #0.
T lines are what I call "pack edges". They are objects that are
not reachable from any other object contained in the same pack.
What this means is that if you have all of the listed objects
for a pack, downloading that pack is useless for you. This of
course requires that your local repository is not partial.
A D line says that pack #1 depends on pack #0. So if you decide
to slurp pack #1 because you wanted to have one object that is
not available as a plain file under objects/??/, you had better
make sure that you have all the objects available in pack #0.
One way to do so is to look at T lines for pack #0 and make sure
you have those "pack edge" objects in the local repository. If
you discover you do not have them, you either need to slurp pack
#0 as well, or start walking the commits from these pack edges.
If http-pull slurped pack #0, which does not depend on anything
else, this would obviously complete the process. However, even
if http-pull chose to walk the commits, if the remote repository
is fully packed, it would end up slurping pack #0. So either
way would work fine in theory, and the choice of which approach
to take really depends on "which one is more efficient".
The only case when walking the commits from pack edges could be
a win is when your local repository have most but not all of the
objects that are in pack #0 on the remote side, and the remote
side has those needed objects lying around unpacked, in addition
to having them in the pack #0. This is very unlikely because
(1) the remote side says pack #1 depends on pack #0, which means
pack #0 is older than pack #1, and (2) we ended up slurping pack
#1, which means objects in pack #1 have already been removed by
"git prune-packed" on the remote side. These two makes it very
likely that objects in pack #0 are already prune-packed on the
remote side. So my recommendation is to just slurp the depended
on pack, pack #0, in this case instead of adding the pack edge
objects to "to be commit-walked" list.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
