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

"Michael S. Tsirkin" [off-list ref] wrote:

quoted

Quoting r. Junio C Hamano [off-list ref]:
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.

So I currently always do git fetch <remote> to download changes,
and always use git pull . <branch> to merge a specific branch.

Agreed; #4 best matches what I (and those I work with on that ugly
repository of mine) do.

My git.git repository currently just fetches all of Junio's branches
right into my local refs/heads.  I fetch every day or so, but never
merge from next into any branch.  Though I create branches off next,
master, or some select commit based on whatever topic I'm hacking.

In my other repositories I tend to fetch before merging, for a
number of reasons:

 a) Its distributed backup; if I fetch the branch that's one more copy.

 b) I can easily view a branch's recent changes, but not affect my
    own topics until I'm ready to take them in.  People often ask
	me to look at their changes, or wonder why something is suddenly
	acting odd - looking at the commits in gitk usually tells me
	quite quickly who did what.  :-)

 c) I can easily start a new topic off any recent change.

 d) I can easily merge topics once they are local and reviewed.

a,b,d are not quite as necessary in an email-patch based group such
as git itself, as the mailing list offers most of the reasons I
fetch first.  b and c are just convience there.

--