On Fri, 26 Oct 2007, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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). > 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@xxxxxxxxxxxx> -Daniel *This .sig left intentionally blank* - 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
