Re: [PATCH] Merge non-first refs that match first refspec

From: Shawn O. Pearce <spearce@spearce.org>
Date: Sep 28, 2007, 05:25 UTC
Message-ID: <20070928052548.GX3099@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0709280108060.5926@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> wrote:

Show 22 quoted lines

> On Fri, 28 Sep 2007, Shawn O. Pearce wrote:
> 
> > Daniel Barkalow <barkalow@iabervon.org> wrote:
> > > Beats me; Junio, what's your test case?
> > 
> > If I understood him correctly it is this:
> > 
> > 	mkdir foo; cd foo; git init
> > 	git config remote.origin.url git://repo.or.cz/alt-git.git
> > 	git config remote.origin.fetch refs/heads/master:refs/remotes/origin/master
> > 	git config --add remote.origin.fetch refs/heads/maint:refs/remotes/origin/maint
> > 	git pull
> > 
> > We should see "master" listed in .git/FETCH_HEAD as a "for-merge"
> > and "maint" listed as a "not-for-merge"...
> > 
> > But if that remote.origin.fetch was a wildcard spec this shouldn't
> > happen as the results are unpredictable.  But above the user
> > explicitly put master first, so it should be defaulted to.
> 
> But after that sequence, the right thing does happen. So I'm guessing that 
> he has some different sequence that triggers a bug.

OK. Then I don't understand what issue Junio identified. And it makes me feel better knowing that the current code does do the right thing in the above case, because that's what I meant for it to do when I was last in there...

-- 
Shawn.