Luben Tuikov [off-list ref] writes:
Questions:
What is the reasonining of defining branch.<name>.merge to point
to the "remote's setup"?
See list archives.
Because you are not required to use remote tracking branches.
By the way, I think we allow the name of the remote tracking
branch as well, but we do not advertise it -- always using
remote's name consistently is much less confusing.
The reasoning is that the remote's setup should only leak into
[remote] and no further. I.e. [remote] is the only one concerned
with the mapping between the remote repo and the local repo.
No. Remote is not about mapping -- if mapping is there you can
talk about it, but that is optional.
Junio C Hamano wrote:
Luben Tuikov [off-list ref] writes:
quoted
Questions:
What is the reasonining of defining branch.<name>.merge to point
to the "remote's setup"?
See list archives.
Because you are not required to use remote tracking branches.
By the way, I think we allow the name of the remote tracking
branch as well, but we do not advertise it -- always using
remote's name consistently is much less confusing.
If remember correctly there were added some magic which makes
git search on pull first remote branches (to allow to pull
without tracking branches), then tracking branches. This I think
supercedes alternate proposal of using branch.<name>.mergeLocal.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--- Junio C Hamano <junkio@cox.net> wrote:
Luben Tuikov [off-list ref] writes:
quoted
Questions:
What is the reasonining of defining branch.<name>.merge to point
to the "remote's setup"?
See list archives.
Because you are not required to use remote tracking branches.
Then why does it point to the _remote_ mapping? One shouldn't
care what it is, and how it looks in the remote repo. That is
handled by [remote]. In [branch] I shouldn't have to have any
absolute references, i.e. branch.<name>.remote points to [remote],
and branch.<name>.merge should only give a _branch_ name,
whose remote-to-local mapping (which preserves the branch name)
can be found by dereferencing branch.<name>.remote to get to
remote.<rname>.fetch.
Think of it as DB schema normalization.
Luben
By the way, I think we allow the name of the remote tracking
branch as well, but we do not advertise it -- always using
remote's name consistently is much less confusing.
quoted
The reasoning is that the remote's setup should only leak into
[remote] and no further. I.e. [remote] is the only one concerned
with the mapping between the remote repo and the local repo.
No. Remote is not about mapping -- if mapping is there you can
talk about it, but that is optional.
Luben Tuikov wrote:
quoted hunk
--- Junio C Hamano <junkio@cox.net> wrote:
quoted
Luben Tuikov [off-list ref] writes:
quoted
Questions:
What is the reasonining of defining branch.<name>.merge to point
to the "remote's setup"?
See list archives.
Because you are not required to use remote tracking branches.
Then why does it point to the _remote_ mapping? One shouldn't
care what it is, and how it looks in the remote repo. That is
handled by [remote]. In [branch] I shouldn't have to have any
absolute references, i.e. branch.<name>.remote points to [remote],
and branch.<name>.merge should only give a _branch_ name,
whose remote-to-local mapping (which preserves the branch name)
can be found by dereferencing branch.<name>.remote to get to
remote.<rname>.fetch.
Once again: if you _don't_ have _local_ tracking branch, so you _must_
use _remote_ name.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git