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.

On Sun, Nov 19, 2006 at 01:29:27AM CET, Junio C Hamano wrote:

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

(Not a plan, that's what I do now. ;-)

Yes, that's correct, but it's not what I'm talking about anymore - sorry
for the confusion. The proper solution for this is of course to move
this around in the refs/ hierarchy out of heads to a more suitable
place. I'm going to do that in few moments.

What I'm talking about now are _real_ user-visible and user-created
refs, which should however stay local to the repository the user created
them in.

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.

I don't think the automatic lookup of the branch with private/ prepended
is too bad a thing, but if you have a better solution...

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.

Yes, but what I have on mind are branches the _user_ wants to declare as
local.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."