Brent Goodrick wrote:
> On Sun, Mar 1, 2009 at 1:20 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote:
> > [...] 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.
>
> Hmmm, maybe, without knowing it.
It's rather hard to rewrite history without knowing it, there are big
warnings all over the relevant tools' manpages...
> 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.
Ironically I cannot reproduce this except with my "own" version that
includes the patch I posted yesterday. I'll have to look into why it
fails to list any refs to the remote. In the meantime please
disregard that patch.
If you still have a repo that can reproduce the problem, please keep a
copy for future investigation, and then try
git fetch-pack -v $url refs/remotes/origin/home 2>&1 \
| git name-rev --stdin
The -v will dump a lot of output about the common commit search. The
message "giving up" indicates that you hit the 256 commit limit; if
that doesn't appear, please include the full output so that we can see
where it stops.
--
Thomas Rast
trast@{inf,student}.ethz.ch
Attachment:
signature.asc
Description: This is a digitally signed message part.
