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

On Thu, 25 Oct 2007, Jeff King wrote:

On Thu, Oct 25, 2007 at 07:32:36AM -0700, Randal L. Schwartz wrote:

quoted

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.

I guess it's a new feature that you can use a branch.*.merge line to 
select a ref that otherwise wouldn't be fetched at all, cause it to be 
fetched, and have it marked for merging; previously, such a config line 
would just be ignored, as it didn't exactly match anything. It's a side 
effect that something that doesn't exist (by that name on the remote side) 
is now an issue.

	-Daniel
*This .sig left intentionally blank*