Re: warning: no common commits - slow pull

From: David Brownell <david-b@pacbell.net>
Date: Mar 10, 2008, 17:18 UTC
Message-ID: <200803101018.09282.david-b@pacbell.net>
In-Reply-To: <alpine.LNX.1.00.0803091443440.19665@iabervon.org>

On Sunday 09 March 2008, Daniel Barkalow wrote:

> Try this. I'm not at all sure that it's doing what I want, but it passes 
> all the current tests, and it should only affect your test case if it's 
> actually right.

Seems to resolve that problem for me ... well timed, in terms of RC5!

But some stuff still looks a bit fishy.  See this RC4 --> RC5 pull:

  remote: Counting objects: 1329, done.
  remote: Compressing objects: 100% (276/276), done.
  remote: Total 908 (delta 749), reused 760 (delta 631)
  Receiving objects: 100% (908/908), 146.35 KiB | 40 KiB/s, done.
  Resolving deltas: 100% (749/749), completed with 287 local objects.
  remote: Counting objects: 1330, done.
  remote: Compressing objects: 100% (277/277), done.
  remote: Total 909 (delta 749), reused 760 (delta 631)
  Receiving objects: 100% (909/909), 146.63 KiB | 38 KiB/s, done.
  Resolving deltas: 100% (749/749), completed with 287 local objects.
  From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
   * [new tag]         v2.6.25-rc5 -> v2.6.25-rc5
  Updating 29e8c3c..cdeeeae
  Fast forward
  Auto packing your repository for optimum performance. You may also
  run "git gc" manually. See "git help gc" for more information.
  ...

That's pretty typical: two count/compress/receive/resolve passes, with almost an identical shape and size. Every time I see that, I suspect that most of the second one should not be needed...

However, the grace of not re-fetching the entire GIT database (at several hundred MBytes) the second time is much appreciated!

- Dave

Show 40 quoted lines

> --- a/builtin-fetch-pack.c
> +++ b/builtin-fetch-pack.c
> @@ -26,6 +26,8 @@ static const char fetch_pack_usage[] =
>  #define SEEN		(1U << 3)
>  #define POPPED		(1U << 4)
>  
> +static int marked;
> +
>  /*
>   * After sending this many "have"s if we do not get any new ACK , we
>   * give up traversing our history.
> @@ -61,6 +63,16 @@ static int rev_list_insert_ref(const char *path, const unsigned char *sha1, int
>  	return 0;
>  }
>  
> +static int clear_marks(const char *path, const unsigned char *sha1, int flag, void *cb_data)
> +{
> +	struct object *o = deref_tag(parse_object(sha1), path, 0);
> +
> +	if (o && o->type == OBJ_COMMIT)
> +		clear_commit_marks((struct commit *)o, 
> +				   COMMON | COMMON_REF | SEEN | POPPED);
> +	return 0;
> +}
> +
>  /*
>     This function marks a rev and its ancestors as common.
>     In some cases, it is desirable to mark only the ancestors (for example
> @@ -153,6 +165,10 @@ static int find_common(int fd[2], unsigned char *result_sha1,
>  	unsigned in_vain = 0;
>  	int got_continue = 0;
>  
> +	if (marked)
> +		for_each_ref(clear_marks, NULL);
> +	marked = 1;
> +
>  	for_each_ref(rev_list_insert_ref, NULL);
>  
>  	fetching = 0;
>