Re: [PATCH] Only warn about missing branch.<n>.merge in pull.

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Dec 19, 2006, 00:59 UTC
Message-ID: <200612190159.58658.Josef.Weidendorfer@gmx.de>
In-Reply-To: <Pine.LNX.4.63.0612182135360.19693@wbgn013.biozentrum.uni-wuerzburg.de>

On Monday 18 December 2006 21:43, Johannes Schindelin wrote:

Show 15 quoted lines

> Hi,
> 
> On Mon, 18 Dec 2006, Junio C Hamano wrote:
> 
> > 	$ git pull second
> > ...
> >  (3) branch.$current.merge was a mistake.  It should have been
> >      branch.$current.merge.$remote.  In other words, the
> >      configuration should have been about the current branch and
> >      the remote repository pair.
> > 
> >  (4) the current configuration mechanism is fine, but the code
> >      is not.  We should forbid "the first branch listed" rule
> >      from being applied for "git pull second", and require the
> >      users to explicitly say which branch(es) to merge.

Show 6 quoted lines

> I fetch/merge criss-crossed over my machines, so this affects me. Until 
> the recent changes, I _always_ fetched/merged with explicit remote and 
> branch. This keeps me unconfused about what I actually do.
> 
> With the options you list, I'd say (3) with (4) as a fallback is the way 
> to go.

I agree. Despite of this, I just sent out the quick fix.

Show 7 quoted lines

> However, I would actually reuse our versatile (often hated?) config  
> handling:
> 
> [branch "xyz"]
> 	remote = blabla # this is the default remote
> 	merge = master # this is the default branch for the default remote
> 	merge = pu for remote second # merge 'pu' if pulling from second

Looks a little bit confusing, but is fine with me. I even would remove the need for the word "remote" in the second merge line. Anybody using this has to look it up in the documentation, anyway. Because these options are not really self-describing.

Josef