Josef Weidendorfer [off-list ref] writes:
... One difference of cloning with GIT vs. with
Cogito is that Git always clones all remote branches. This can
be limiting if you want to work with multiple repositories,
but allows you to immediatly work with all the branches.
Three points, and two footnotes.
. After a git clone, you can still fetch from non-origin
repository; you can also set up .git/remotes/somewhere-else if
you pull from the non-origin repository regularly, so it is
not really "limiting". It is just being slightly less
convenient, in that setting up for the origin is done for you
by clone [*1*] while you have to arrange for non-origin
repository yourself afterwards.
. The namespace under refs/heads is and always will be an issue.
It is a local matter and how remote branches are named should
not dictate what local branch names you can use in your
repository, but that essentially is what happens after
git-clone to users who do not rename those branches from the
initial cloning.
I once considered to give an option to clone to map the origin
heads to .git/refs/heads/origin/{master,maint,pu,...}. In
hindsight that might have been cleaner. Instead I just followed
what Cogito already established, and mapped remote "master" to
"origin".
. The namespace under refs/tags theoretically also has the same
issue, but I suspect it would not matter too much in practice.
The tags people fetches from remote tend to be release-point
tags (e.g. v2.6.14) whose names implicitly follow an obvious
(to humans) naming convention; when you name your temporary
anchor points using lightweight tags, you can easily avoid
name clashes with those "for other people" tags [*2*].
[Footnotes]
*1* Actually, even the setting up for the origin is done only
halfway -- it only arranges 'git fetch/pull' to fetch from the
master branch, and other branches are not tracked unless you
explicitly arrange them to be. This is somewhat deliberate; the
refs/ namespace management is a local matter and you do not
necessarily want to keep tracking all the branches from origin.
*2* This becomes somewhat problematic when the tool
automatically follows/fetches tags, and that is why git-core
barebone Porcelainish requires an explicit 'git fetch --tags'.
On Friday 04 November 2005 18:43, Junio C Hamano wrote:
Josef Weidendorfer [off-list ref] writes:
quoted
... One difference of cloning with GIT vs. with
Cogito is that Git always clones all remote branches. This can
be limiting if you want to work with multiple repositories,
but allows you to immediatly work with all the branches.
Three points, and two footnotes.
. After a git clone, you can still fetch from non-origin
repository; you can also set up .git/remotes/somewhere-else if
you pull from the non-origin repository regularly, so it is
not really "limiting".
With "limiting" I only meant the fact that all the refs/heads names are
copied over, thus polluting your local namespace. Additionally, it can
be some transfer burden to copy all the objects instead only the objects
needed for one head.
Cogito does not have an issue with pollution of refs/heads namespace
as it only clones one head to the special "origin" head [*1*].
But as I said, the Git way can be more convenient. I think that the
proposed "implicit remote branches" are a way between: make it convenient
for Cogito users to fast access branches from the origin repository, but
pollute the name space only "a little".
[*1*] Still, it would be nice to specify the name of the branch tracking
the origin repository via on option in cg-clone (defaulting to "origin"),
and to also be able to specify the head which is branched off and you
are put on after cloning (defaulting to "master"); but I do not think
there is much use to such flexibility.
It is just being slightly less
convenient, in that setting up for the origin is done for you
by clone [*1*] while you have to arrange for non-origin
repository yourself afterwards.
I do not think there is much difference in editing files under
.git/remotes, or using cg-branch-add.
. The namespace under refs/heads is and always will be an issue.
It is a local matter and how remote branches are named should
not dictate what local branch names you can use in your
repository, but that essentially is what happens after
git-clone to users who do not rename those branches from the
initial cloning.
Yes, and that is nice about Cogito.
I once considered to give an option to clone to map the origin
heads to .git/refs/heads/origin/{master,maint,pu,...}. In
hindsight that might have been cleaner. Instead I just followed
what Cogito already established, and mapped remote "master" to
"origin".
That is a nice idea. What is the exact compatiblity problem with Cogito
here? Either a repository is cloned with Git or with Cogito, and
afterwards, both should be able to cope with any naming scheme.
Both Git and Cogito do setup local "master" for local work after cloning.
To still be able to track a remote "master", this is mapped to local
"origin". Am I right here?
What happens if the remote side itself has an "origin" head?
[Footnotes]
*1* Actually, even the setting up for the origin is done only
halfway -- it only arranges 'git fetch/pull' to fetch from the
master branch, and other branches are not tracked unless you
explicitly arrange them to be. This is somewhat deliberate; the
refs/ namespace management is a local matter and you do not
necessarily want to keep tracking all the branches from origin.
Yes. I do not see any problem here with explicitly specifying a
head you want to track in "git fetch origin <head>". Still, I would
not call this syntax 'porcelainish'.
But we have Cogito for this.
*2* This becomes somewhat problematic when the tool
automatically follows/fetches tags, and that is why git-core
barebone Porcelainish requires an explicit 'git fetch --tags'.
Ah, ok.
Josef
Dear diary, on Fri, Nov 04, 2005 at 06:43:04PM CET, I got a letter
where Junio C Hamano [off-list ref] told me that...
I once considered to give an option to clone to map the origin
heads to .git/refs/heads/origin/{master,maint,pu,...}. In
hindsight that might have been cleaner. Instead I just followed
what Cogito already established, and mapped remote "master" to
"origin".
Well, that obviously works only when you resign on the workflow where
pull means fetch + merge, since your local master would conflict with
the remote master, therefore having nowhere to store the remote master.
. The namespace under refs/tags theoretically also has the same
issue, but I suspect it would not matter too much in practice.
The tags people fetches from remote tend to be release-point
tags (e.g. v2.6.14) whose names implicitly follow an obvious
(to humans) naming convention; when you name your temporary
anchor points using lightweight tags, you can easily avoid
name clashes with those "for other people" tags [*2*].
I still believe we need the notion of private tags which shouldn't be
cloned.
Hmm. Wait.
All right. git-update-server-info ignores hidden refs, but referencing a
hidden ref works all right (unsurprisingly). So let's just codify that
private tags which shan't be fetched (unless requested explicitly) start
with a dot (/^\./) and we are all set...?
--
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.