On Sun, Mar 1, 2009 at 1:20 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
