Junio C Hamano <junkio@cox.net> writes:

quoted text
>> What about leading underscore?
>
> I would rather prefer to do refs/{heads,private}/ and allow
> checkout to treat either of them as branches.  We are talking
> about allowing checkout to go to a non-branch by storing a raw
> commit object name in HEAD instead of leaving it as a symref, so
> we know we are going to touch that area already.

Oops.  Consider this rescinded.  I myself already talked about
"not necessarily just public vs private".  Silly me.

I think this is related to the common gripe of "why can't Junio
mark pu to be rewinded in his public repository".  We should be
able to leave the branch grouping to users.

Not just public vs private, but I can see an organization that
uses something like this:

    heads/1.5/{maint,master,next,pu} are to maintain and advance 1.5 series
    heads/1.5/topics/{foo,bar} are topics applicable to 1.5
    heads/2.0/{maint,master,next,pu} are to maintain and advance 2.0 series
    heads/2.0/topics/{foo,bar} are topics applicable only to 2.0
    heads/topics/{frotz,nitfol} are topics applicable to both

and wanting to view all the topics, only things related to 1.5,
etc.  So Porcelains _can_ enforce their own policies to arrange
things differently but we should also be able to let the users
(and project branch naming policy) to do what we've been talking
about by saying:

	use heads/private/ for your own stuff.  And have
	configuration that says "heads/private/" are private
	branches that are not subject to default
	pushing/pulling.

The real instruction from the project would say what the syntax
for telling that to git but I think you got the idea...

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html