[PATCH] fetch-pack: avoid packing reachable objects.

[PATCH] fetch-pack: avoid packing reachable objects.

[Jan Harkes]

Mark remote commits that were found in the alternate repository as
COMPLETE and avoid unnecessary packing of already available objects.

Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
---

When we pull updates from a shared repository into a clone that was
created with 'git clone -l -s', we pack objects that are already
reachable. This was because we only marked local refs as COMPLETE.

diff --git a/fetch-pack.c b/fetch-pack.c
index 8566ab1..17524d8 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -169,6 +169,7 @@ static int everything_local(struct ref *
 		 */
 		if (o->type == commit_type) {
 			struct commit *commit = (struct commit *)o;
+			commit->object.flags |= COMPLETE;
 			if (!cutoff || cutoff < commit->date)
 				cutoff = commit->date;
 		}

Re: [PATCH] fetch-pack: avoid packing reachable objects.

[Junio C Hamano]

Jan Harkes <jaharkes@cs.cmu.edu> writes:

> Mark remote commits that were found in the alternate repository as
> COMPLETE and avoid unnecessary packing of already available objects.

Sorry, this is wrong (we made this mistake twice already).  The
mere existence of that object in the local repository does not
necessarily mean we have everything that is reachable from it.

The rule is that we only trust local refs.  Anything that are
reachable from them are known to be complete.  And after a
successful fetch, we update local refs.  The existence of an
object is a strong _hint_ that it _might_ be complete, but
nothing more.

Think of a case where you tried to fetch via commit walker and
got things reachable from the then-current ref, and the 
object you are marking as COMPLETE (maybe in pack) is a remnant
of that failed fetch, which was killed before completing.  You
might have complete history starting from the then-current
commit back to that commit, but there is no guarantee that you
can further tangle the history back and find everything needed.