Re: [PATCH] Do not ignore hidden refs

Petr Baudis [off-list ref] writes:

On Sat, Nov 18, 2006 at 09:05:12PM CET, Junio C Hamano wrote:

quoted

	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.