Re: recent change in git.git/master broke my repos

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 27, 2007, 20:06 UTC
Message-ID: <Pine.LNX.4.64.0710271600440.7345@iabervon.org>
In-Reply-To: <7vejfhulzn.fsf@gitster.siamese.dyndns.org>

On Fri, 26 Oct 2007, Junio C Hamano wrote:

Show 46 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > On Thu, 25 Oct 2007, Jeff King wrote:
> >
> >> On Thu, Oct 25, 2007 at 07:32:36AM -0700, Randal L. Schwartz wrote:
> >> 
> >> > I have echo "ref: refs/remotes/origin/master" >.git/refs/heads/upstream
> >> > so that my daily update script can go:
> >> > 
> >> >    git-fetch
> >> >    if [ repo is on master, and is not dirty ];
> >> >       git-merge upstream
> >> >    fi
> >> > 
> >> > Yesterday that worked.
> >> > 
> >> > Today I get a rash of:
> >> > 
> >> >   fatal: Couldn't find remote ref refs/remotes/origin/master
> >> > 
> >> > from my git-fetch.
> >> 
> >> Randal and I discussed this a bit on IRC, and it turns out not to be
> >> related to the 'upstream' symref. Instead, he had a broken
> >> branch.master.merge config that pointed to "refs/remotes/origin/master"
> >> (which you can see from his script above doesn't actually get used).
> >> 
> >> So presumably the old git-fetch didn't care that the contents of
> >> branch.*.master didn't exist (it's just that nothing got marked for
> >> merging), but the one just merged from the db/fetch-pack topic does.
> >> 
> >> Is this behavior change intentional?
> >
> > It's not exactly intentional; it's just that nobody seems to have tested 
> > this particular misconfiguration. It should probably report an error 
> > (since the configuration is, in fact, broken and potentially misleading), 
> > but it probably shouldn't be fatal and certainly shouldn't be so 
> > uninformative.
> 
> How would we proceed from here, then?
> 
> If you had "branch.master.merge = refs/heads/foobar", kept
> running happily, and suddenly the remote stopped carrying that
> foobar branch, you would get a configuration that uses
> nonexistent remote branch name, so this is not purely a
> configuration error on the fetcher's side.

True, although I'd consider that a matter of configuration rot rather than it being an okay configuration; the user probably still needs to figure out what happened to it and what to use instead. Maybe we want to output a message to stderr (although higher than the die() used to be, so that we can report the reason that it was looking for the missing remote ref).

Show 12 quoted lines

> Older git used to enumerate remote tracking branches explicitly,
> and one of the remote.origin.fetch entries would have said
> "refs/heads/foobar:refs/remotes/origin/foobar", and that would
> have made git-fetch fail with the error, complaining that such a
> branch does not exist.
> 
> You are suggesting that git-fetch should not fail if
> remote.origin.fetch is refs/heads/*:refs/remotes/origin/*
> wildcard, and I think I can agree with that; "git pull" however
> should notice and and exit with an error.
> 
> Perhaps something like this?

That looks like what I was going to write when I got to it (although I would have had the flag inverted, which is less git style, I guess).

Acked-By: Daniel Barkalow <barkalow@iabervon.org>

	-Daniel
*This .sig left intentionally blank*