git-fetch-pack: avoid unnecessary zero packing
commit844ac7f81874f7acf22a15ffd985048d930c8341
authorLinus Torvalds <torvalds@osdl.org>
Wed, 19 Oct 2005 06:52:08 +0000 (18 23:52 -0700)
committerJunio C Hamano <junkio@cox.net>
Wed, 19 Oct 2005 06:52:08 +0000 (18 23:52 -0700)
tree63bb5f70d85c9563122f81165932c4ffc10754fe
parentc99ec048bf386ed2b28086cb3756af2dc91fc3d2
git-fetch-pack: avoid unnecessary zero packing

If everything is up-to-date locally, we don't need to even ask for a
pack-file from the remote, or try to unpack it.

This is especially important for tags - since the pack-file common commit
logic is based purely on the commit history, it will never be able to find
a common tag, and will thus always end up re-fetching them.

Especially notably, if the tag points to a non-commit (eg a tagged tree),
the pack-file would be unnecessarily big, just because it cannot any most
recent common point between commits for pruning.

Short-circuiting the case where we already have that reference means that
we avoid a lot of these in the common case.

NOTE! This only matches remote ref names against the same local name,
which works well for tags, but is not as generic as it could be. If we
ever need to, we could match against _any_ local ref (if we have it, we
have it), but this "match against same name" is simpler and more
efficient, and covers the common case.

Renaming of refs is common for branch heads, but since those are always
commits, the pack-file generation can optimize that case.

In some cases we might still end up fetching pack-files unnecessarily, but
this at least avoids the re-fetching of tags over and over if you use a
regular

git fetch --tags ...

which was the main reason behind the change.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fetch-pack.c