> Quoting r. Junio C Hamano <junkio@xxxxxxx>: > Subject: Re: [PATCH] Only warn about missing branch.<n>.merge in pull. > > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > Commit 62b339a5 added a warning for git-pull to notify the user when > > they have not configured the setting 'branch.<n>.merge' (where <n> > > is the current branch) and no arguments were given to git-pull to > > specify the branches to merge. > > Let's step back a bit. I have a question that affects the > design level. > > To people who interact with more than one remote repositories > regularly, how would you normally work, and how well does the > current configuration mechanism help you? I am not interested > in somebody who cut & paste full URL and branch name from pull > request e-mail, but those who interact with the same remotes > regularly and have entries in $GIT_DIR/remotes/ for them (or > their moral equivalent remote.* configuration). > > You can have one "default remote" per branch (and it being the > default, one is the only number that can make sense), and you > can say: > > $ git pull > > without saying anything about which remote, and it does "git > pull origin" or whatever the default remote is. That's a good > thing. > > Also, the change by 62b339a5 makes it an error not to have the > corresponding branch.$current.merge, if the above syntax that > does not say any remote nor branches is used. That's also a > good thing. > > But if you regularly interact with two remote repositories, and > the second one (which by definition cannot be the default for > the current branch) has $GIT_DIR/remotes/second (again, or its > moral equivalent, remote.second.* configuration), then wouldn't > you expect that when you say: > > $ git pull second > > some mechanism protects you from merging "the first remote > branch listed in $GIT_DIR/remotes/" the same way? > > I can see a few possibilities: > > (1) people do not interact with multiple remote repositories > regularly, so this is not a problem in practice. > > (2) people do, but "the first branch listed" rule is good > enough in practice. Because they would always say "git > pull second which-branch" instead if they want something > different, this is a non-issue. > > (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 am inclined to say that (1) is possible, (2) is implausible > (otherwise we would not have done 62b339a5 for the same reason), > (3) is confused, and probably (4) is what we need. As a person who tracks multiple remotes in one repository, I would say (4) best matches what I do. I never remember which branch will git pull merge. So I currently always do git fetch <remote> to download changes, and always use git pull . <branch> to merge a specific branch. HTH -- MST - 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