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

2 messages, 2 authors, 2016-08-11 · open the first message on its own page

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

From: Josef Weidendorfer <hidden>
Date: 2016-08-11 19:43:49

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

On Mon, 18 Dec 2006, Junio C Hamano wrote:
quoted
	$ 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.
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.
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

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

From: Johannes Schindelin <hidden>
Date: 2016-08-11 20:31:36

Hi,

On Tue, 19 Dec 2006, Josef Weidendorfer wrote:
On Monday 18 December 2006 21:43, Johannes Schindelin wrote:
quoted
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.
Granted. Suggestions?
I even would remove the need for the word "remote" in the second merge 
line.
No. In Git, a line like

	blabla

would turn into a boolean named "blabla" being true.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help