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

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:10

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