Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories

From: Petr Baudis <hidden>
Date: 2016-06-15 22:42:11

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help