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

[Thomas Rast <trast@student.ethz.ch>]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

Brent Goodrick wrote:
> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]