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