Linus Torvalds [off-list ref] writes:
I don't like the dot idea, but it certainly _would_ make sense to have a
local prefix.
We could even make it a _totally_ different namespace:
.git/refs/local/heads
.git/refs/local/tags
which means that even if you call a local head the same thing as a global
one, both can still exist.
Then, make "origin" always be a local head.
While that is logically the right thing to do, it is somewhat
confusing to see all those branch heads we obtained from the
remote side stored as our "local" branches -- meaning they are
private to us.
Just for discussion, I'd suggest a less structured approach as
an alternative, and making it just a convention.
- clone by default [*1*] creates .git/refs/heads/origin/*
heads; your "master" becomes my "origin/master".
Interestingly but logically, if your repository was cloned
from somewhere else, you would have "origin/master", which
would become my "origin/origin/master".
- clone creates remotes/origin that knows all branches from the
origin as copied by the above process, as suggested by Daniel
in the other thread.
Then we would have a recommended workflow example that uses
origin/* as reference branches after they are set up. After
becoming familiar with this setup, when people fetch/pull from
more than one repository, they can configure things correctly by
emulating what clone did to the "origin" remote repository for
them.
[Footnote]
*1* I say "by default" here; I think there should be an
operating mode for git clone that acts as a straight copy, not
even the current "HEAD" -> "origin" renaming. In fact that is
what you do with low-level git-clone-pack.
Dear diary, on Sun, Nov 06, 2005 at 10:11:10AM CET, I got a letter
where Junio C Hamano [off-list ref] told me that...
Just for discussion, I'd suggest a less structured approach as
an alternative, and making it just a convention.
The problem is that at least Cogito defaults to the 'origin' branch when
pulling/merging, so if you'll have 'origin/master' instead of 'origin',
I will have to hack that around. So it's not _just_ a convention but
something reflected in some code as well.
- clone by default [*1*] creates .git/refs/heads/origin/*
heads; your "master" becomes my "origin/master".
Interestingly but logically, if your repository was cloned
from somewhere else, you would have "origin/master", which
would become my "origin/origin/master".
This loses the pretty nice property that 'origin' refers to the HEAD
branch of the remote repository, no matter how is it called (well, it is
nice as long as the remote repository doesn't _switch_ the HEAD to some
non-superset branch; but repositories you're cloning from shouldn't do
that). So you should either have origin/HEAD locally, or make the
'master' branch more "socially canonical".
*1* I say "by default" here; I think there should be an
operating mode for git clone that acts as a straight copy, not
even the current "HEAD" -> "origin" renaming. In fact that is
what you do with low-level git-clone-pack.
What would it be useful for?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
On Tuesday 08 November 2005 00:21, Petr Baudis wrote:
The problem is that at least Cogito defaults to the 'origin' branch when
pulling/merging, so if you'll have 'origin/master' instead of 'origin',
I will have to hack that around. So it's not _just_ a convention but
something reflected in some code as well.
The new git-clone simply would not produce an "origin" branch at all, and I do
not think Cogito expects that a repository always has an "origin" branch.
The following fact (Git's default clone setup until now, Cogito's clone setup)
"origin" tracks remote "master", to be merged into local "master"
has to be stored into some configuration file, and not to be set up implicitly
as it is done currently. Then you take this setup from the configuration, and
there never would be something hardcoded, and Junios suggestion would be a
convention.
Git already stores half of this into remotes/repo: the "Pull" lines specify
which local head tracks which remote head; the same with Cogito's .git/branches.
Missing in both cases is the information that "origin" maps to the local
development head "master". More common name for this information: "origin" is
the upstream for "master".
This information is useful at least for two cases:
(1) for specifying the default action to be done on "git-pull" or "cg-update",
and (2) try to prohibit accidental bogus merges.
The default action currently is either hardcoded (Cogito) or working somehow
by luck (Git: you have to be on "master" for git-pull).
AFAIK, Cogito prohibits bogus merges by enforcing to be either on "master"
or to be in a not-mergeable state (cg-seeking).
Merge relationship is useful to be specified not only for upstream direction,
but also for branches which branched off the current head and should be
merged back (e.g. topical branches). For this, multiple branches to be
merged with "git pull" should be specifyable.
Where to put the information about default merge relation?
Both .git/remotes and .git/branches are candidates, but merge relation
also makes sense for local branches, i.e. git-branch <branch> <origbranch>
should set up to merge from <origbranch> if you are on <branch> by default.
Similarly, it should set up a relation the other way to state that it is
useful to merge from <branch> into <origbranch> (this is for (2) above).
A possiblity would be to put the merge relationship into .git/config:
[master]
merge-canditate: origin
merge-default: origin
Problem here is that head names should not appear in key names,
because key names are case insensitive :-(
A possibility would be for config keys to become case sensitive after a ":"
(of course only for toplevel keys):
[head:master]
merge-default: origin
quoted
- clone by default [*1*] creates .git/refs/heads/origin/*
heads; your "master" becomes my "origin/master".
Interestingly but logically, if your repository was cloned
from somewhere else, you would have "origin/master", which
would become my "origin/origin/master".
This loses the pretty nice property that 'origin' refers to the HEAD
branch of the remote repository, no matter how is it called (well, it is
nice as long as the remote repository doesn't _switch_ the HEAD to some
non-superset branch; but repositories you're cloning from shouldn't do
that). So you should either have origin/HEAD locally, or make the
'master' branch more "socially canonical".
Ah, so git-clone sets up a local development head for the remote HEAD, which
does not always have to be "master", right? This information would be available
by the proposed storing of merge relationship: local "master" wants get merges
from remote HEAD to be updated.
Josef