Re: "warning: no common commits" triggered due to change of remote's IP address?

From: Thomas Rast <trast@student.ethz.ch>
Date: Mar 1, 2009, 21:20 UTC
Message-ID: <200903012221.03662.trast@student.ethz.ch>
In-Reply-To: <e38bce640903011001p2d705707o9f7145ab5ab68929@mail.gmail.com>

Brent Goodrick wrote:

Show 6 quoted lines

> My expectation at this point is that, since I've changed only the IP
> address, and kept everything else the same, git should be smart enough
> to compare SHA1 values only and not download the entire remote repo
> just to do that comparison.
> 
> But I was quite surprised to find that it was pulling down tons of data:

Git doesn't care about the details of the transport; during its handshake, lists of the available refs are exchanged, and then used to determine the common commits. So I'm also rather surprised.

However, your use of + refspecs in

>   gitw fetch 88.99.100.101:git.repos/environ.git
> +refs/heads/home:refs/remotes/origin/home

makes me wonder: have you rewritten the repo hosting 'home' between two fetches? Using (especially, but not only) git-filter-branch can easily render your history disjoint from the pre-filtering state.

>   warning: no common commits

Either your history is very short and really has no common commits whatsoever, or it gave up because of the 256 revision limit during find_common().

IIRC it walks by date, so it is enough to make 256 local commits with a new timestamp to hit that limit. I posted some experimental code two months ago that would use a bisection algorithm, so that it is harder to hit the limit and faster at detecting disjoint history, but nobody had the time to review it.

I'll follow up with the patch if you want to try it. The problem is it's quite large _and_ I don't run any git servers where I could give it a good testing. You'll have to apply it to both sides.

(It does have the nice side-effect of saving the uploading side a bit of work.)

>  1. Will terminating the git fetch like I did leave the satellite repo
>     in an inconsistent state? If so, is my only choice to start
>     a new repo from scratch on the satellite machine, or is there some
>     repair mechanism?

It will just leave a temporary pack file that git-gc will eventually remove. You can just try another fetch later.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch