Jeff King <peff@xxxxxxxx> writes:
> On Tue, Jan 02, 2007 at 09:32:30AM -0800, Junio C Hamano wrote:
>
>> If we are to worry about, and I think we might have to, I think
>> not worrying about mergelocal and not accepting the name of
>> local tracking branch is the only sensible thing to do.
>
> Sorry, I don't see the problem with mergelocal. Can you elaborate?
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.
-
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