Luben Tuikov [off-list ref] writes:
quoted hunk
--- "J. Bruce Fields" <bfields@fieldses.org> wrote:
...
quoted
-The common `Pull: master:origin` mapping of a remote `master`
-branch to a local `origin` branch, which is then merged to a
-local development branch, again typically named `master`, is made
-when you run `git clone` for you to follow this pattern.
So is this no longer the case?
Can someone please bring me up to date?
What is going on?
What's going on is clean-up towards v1.5.0-rc1 ;-).
- 'git clone' does not create a file that has a line that looks
like "Pull: master:origin" anywhere anymore.
- 'git clone' also does not create the traditional "'master' is
special and we map that to origin, others are mapped as is
under refs/heads/, and we have to drop 'origin' from the
remote side because that name we want to use to store their
'master'" layout.
So after a clone, you would get:
[remote "origin"]
url = ....
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
This configuration still causes "git pull" or "git pull origin"
while on "master" to fetch and store the remote side's master as
what you can refer to as 'origin' (because it expands to
'remotes/origin/HEAD' thanks to sha1_name.c::get_sha1_basic()),
and then merges that to your current branch, so there is no
change in the user experience in the big picture, but what is
created to achieve that effect is different from what was
described.
Junio C Hamano wrote:
So after a clone, you would get:
[remote "origin"]
url = ....
fetch = refs/heads/*:refs/remotes/origin/*
By the way, I have thought that you would also get (to avoid nasty
"we don't know which branch is first in glob")
fetch = refs/heads/master:refs/remotes/origin/master
or
fetch = refs/heads/master:refs/remotes/origin/HEAD
(if master was current branch)
[branch "master"]
remote = origin
merge = refs/heads/master
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--- Junio C Hamano <junkio@cox.net> wrote:
What's going on is clean-up towards v1.5.0-rc1 ;-).
- 'git clone' does not create a file that has a line that looks
like "Pull: master:origin" anywhere anymore.
- 'git clone' also does not create the traditional "'master' is
special and we map that to origin, others are mapped as is
under refs/heads/, and we have to drop 'origin' from the
remote side because that name we want to use to store their
'master'" layout.
So after a clone, you would get:
[remote "origin"]
url = ....
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
This configuration still causes "git pull" or "git pull origin"
while on "master" to fetch and store the remote side's master as
what you can refer to as 'origin' (because it expands to
'remotes/origin/HEAD' thanks to sha1_name.c::get_sha1_basic()),
and then merges that to your current branch, so there is no
change in the user experience in the big picture, but what is
created to achieve that effect is different from what was
described.
Ah, I see. Thanks Junio.
... And this is why I see some objections as to what I'm proposing
because it extends too far the extension itself of the old
behavior. (See below.)
Questions:
What is the reasonining of defining branch.<name>.merge to point
to the "remote's setup"? I would much, much rather stop the leak
of the remote's setup right at [remote] and contain it there,
while everything in [branch] would refer to local stuff.
So the above configuration would become:
[remote "origin"]
url = ....
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
# merge gives the place and name of the remote branch locally mapped
merge = refs/heads/origin/master
# OR, better yet
# merge gives the name only of the remote branch to be merged
# the local mapping can be found from "remote = " above
merge = master
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.
Then, [branch] only talks about local relationships. Now
since [branch] does refer to _where_ the local mapping resolves
to, i.e. the right hand part of `:', then there is a redundancy
in branch.<name>.merge, since branch.<name>.remote _does refer_
to [remote] where we can find where it is locally mapped.
Thus, by reducibility, branch.name.merge should only contain
a name. Here is the dependency graph:
branch.name.merge <- (gives a local name)
branch.name.remote <- (gives the remote)
remote.rname.fetch <- (gives the remote:local name mapping)
remote.rname.url (gives the URL).
Now as to what I'm talking about, should be able to be had with:
[remote "parent"]
url = .
fetch = :
[branch "A"]
remote = parent
merge = master
[branch "B"]
remote = parent
merge = A
[branch "C"]
remote = parent
merge = B
Luben