Re: [PATCH] Do not ignore hidden refs

[Petr Baudis <pasky@suse.cz>]

On Sat, Nov 18, 2006 at 05:39:34AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> 
> > Some of the ref manipulation tools (git-for-each-ref and git-show-ref in
> > particular) would not handle hidden (~ /^\./) refs.
> 
> refs.c::check_ref_format() seems to suggest that any ref whose
> path component begins with a dot is invalid (since October last
> year), so I am a bit surprised you are bringing this up now.

Oops, I must've forgotten that already.

> Do you know of specific examples where this is not enforced?  It
> could even be argued that the places in the system that allow
> such a ref are buggy.

Cogito creates such refs for internal purposes in two scenarios, on the
other hand it could be argued that in one of those cases the file has no
business in refs/ at all (temporary fetching refs, but they may be
actually symrefs) and in the other case it has no business in refs/heads/
at all (pointers to shelved changes in a branch).

However, I in fact *did* intend to make leading-dot refnames a public
interface. The thing is, I need a way to mark some tags as private to
your repository if Cogito is to support autopushing tags, and I still
think the most elegant way to do that is to make them like hidden files.
Alternative suggestions welcome.

I don't *need* but it might be nice to have also private heads, for
possible setups when you declare heads namespace of two repositories
matching 1:1 but would like to temporarily make a short-lived head in
one of them or so.

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