Re: [PATCH] Do not ignore hidden refs

From: Junio C Hamano <junkio@cox.net>
Date: Nov 18, 2006, 20:05 UTC
Message-ID: <7vy7q8bjwn.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vejs0cz5s.fsf@assigned-by-dhcp.cox.net>

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

Show 7 quoted lines

>> 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...