Petr Baudis <pasky@xxxxxxx> writes:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html