Re: confusion over the new branch and merge config

Jeff King <peff@peff.net> writes:

I might have misread what you meant by mergeLocal, and you might be trying to introduce a default for "git merge" so that without anything on the command line "git merge" would merge something locally available depending on which branch you are on.

But I did not think of that, and thought you were saying "look at branch.*.mergelocal (if exists) in the same place we look at branch.*.merge in the current code, and just like the latter is used to match up with the remote refname we just fetched, use the former to match the local tracking branches, to decide what to merge". And if that is what you meant by mergelocal, I do not see much advantage in that approach -- that is what I meant in the response. The remote name is available whether you use tracking branches locally or not, so using that to specify the merge operation that happens after a 'pull' is more consistent, less confusing, and matches the long-hand "git pull $URL remote-branch" a lot better than having another configuration that can be used only half the time.

Some people repeatedly argued that remote branch names do not matter. I think they are wrong and are missing the point of distributedness of git. You are fetching from there, so you need to know the name the other end gives them in the first place. But much more importantly, the fact you are fetching from there means some other people could also be fetching from the same place. Now how would you discuss what that common repository recently placed on that branch? You would not use the local tracking branch name which _is_ meaningless to the other person. You use the remote name.

For example, I have a separate repository (that happens to be checked out in Meta/ subdirectory of my main working area, so its control files are in Meta/.git repository) to keep things that I push to my 'todo' branch. After I push the updates to 'todo' out to kernel.org from that repository, I usually fetch from kernel.org into that repository, so that I can later see up to which one I have already pushed out. I am old fashioned and still use remotes and non 'separate-remote' layout for this:

	URL: kernel.org:/pub/scm/git/git.git
        Push: refs/heads/master:refs/heads/todo
        Pull: refs/heads/todo:refs/heads/ko

As you can see from the above, my 'ko' is the local tracking branch, and 'master' in that repository is what is known as 'todo' to the public. But when I talk about what I have in that branch, I would never say 'master' nor 'ko' -- people would not care how I call that branch locally in my private repository. What's private is private and does not matter to others. Instead I would say something like "my 'todo' branch has drafts for v1.5.0 release notes these days".

What does this all mean? It means that remote branch names matter more when you are talking about external communication. And "git pull" (more so for "git fetch") is all about external communication.

Obviously, the local names should matter more when you are doing local operations. So if you are using mergeLocal to give a shorthand to "git merge" that does not explicitly say what to merge, the above discussion does not apply. But if that is the case, mergeLocal should also not affect the selection of branches to be merged when "git pull" happens from a remote either.