Re: [PATCH] Do not ignore hidden refs
- From
Petr Baudis <pasky@suse.cz>
- Date
- Nov 18, 2006, 04:53 UTC
- Message-ID
- <20061118045323.GK7201@pasky.or.cz>
- In-Reply-To
- <7v8xi9fjw9.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 18, 2006 at 05:39:34AM CET, Junio C Hamano wrote:
Show 8 quoted lines
> 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."