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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
