On Monday 18 December 2006 21:43, Johannes Schindelin wrote: > 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. > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html