Re: [PATCH] Do not ignore hidden refs

From: Junio C Hamano <junkio@cox.net>
Date: Nov 19, 2006, 00:29 UTC
Message-ID: <7vmz6o9t3s.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061118231842.GS7201@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 15 quoted lines

> On Sat, Nov 18, 2006 at 09:05:12PM CET, Junio C Hamano wrote:
>> 	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...
>
> Yes, I fully agree that being able to have this configurable is cool,
> but I'm still interested in providing a sensible out-of-the-box default
> configuration for Cogito to use. But if we can agree that heads/private/
> and tags/private/ are good BCP candidates, that's great. (The only
> possible problem is a lot of typing incurred. Perhaps the default refs
> search order should become configurable first.)

It is not clear from the discussion so far why it is necessary (or even is a good change), and I suspect a confusion to mix up two different things has slipped in somewhere in the discussion.

My understanding of your original plan was to use ".foo" as a private thing for Cogito to use to implement some cleverness when the user talks about the branch "foo" (just like StGIT uses "refs/bases/foo" to keep track of its private stuff related to user branch "foo"). When the user says "my 'foo' branch", you were going to munge that name into ".foo" and use both to implement that cleverness (just like StGIT uses "refs/bases/foo" in addition to "refs/heads/foo" when the user is talking about his branch "foo").

I would rather think that it would actively be a bad thing to make the core level to consider heads/private/foo and heads/foo ambiguous. When the user says "my 'foo' branch" that should mean the "foo" branch not the "private/foo" branch.

Which certainly suggests that heads/private/, as a user visible convention to keep developer-repository private stuff for local use, is too verbose.

StGIT's use of refs/bases (i.e. outside refs/heads) is probably sensible because it is not something the end user should directly muck with nor check out. If Porcelains want some "special branch" for their own use to do their magic, however, the ref cannot be outside refs/heads for it to be pointed at by HEAD to become the "current branch" ("bisect" command comes to mind, and I suspect "cg-seek" would have similar issues). But that kind of use is all under controll of the Porcelain, and I would imagine "too long to type" objection would not apply.