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

[Brent Goodrick <bgoodr@gmail.com>]

On Sun, Mar 1, 2009 at 1:20 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> 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().

Hmmm, maybe, without knowing it. Originally, that section of the
.git/config file had "*"'s where "home" was. To clarify, the original
was:

[remote "origin"]
	url = <some_ip_address>:git.repos/environ.git
	fetch = +refs/heads/*:refs/remotes/origin/*

and the current one is now:

[remote "origin"]
	url = <some_ip_address>:git.repos/environ.git
	fetch = +refs/heads/home:refs/remotes/origin/home

Maybe I had made that change and this is the first time I am doing a
fetch to using that change. I thinking that was the cause of this,
because I retried doing a fetch into a separate throw-away repo with
just the change of IP address, and it did not need to fetch anything
more. I had not executed git-filter-branch at all.

>>  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.

Good, that is what I would have expected.

Brent