From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Fri, 20 Mar 2009 21:48:16 GMT
Subject: Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
Message-ID: <alpine.DEB.1.00.0903202246060.6865@intel-tinevez-2-302>
In-Reply-To: <alpine.LNX.1.00.0903201515490.19665@iabervon.org>

Hi,

On Fri, 20 Mar 2009, Daniel Barkalow wrote:

> On Fri, 20 Mar 2009, Junio C Hamano wrote:
> 
> > Petr Baudis <pasky@suse.cz> writes:
> > 
> > >> "git branch" I agree with, but not "git update-ref".  As plumbing, 
> > >> the latter should be much more allowing, feeding rope aplenty (but 
> > >> also allowing cool tricks we do not think about yet).
> > >
> > > We shouldn't allow creating insane ref names even with update-ref. 
> > > That way porcelains cannot rely on update-ref to sanity check the 
> > > user's crap. At most, maybe you might want to bypass this check with 
> > > some force switch, though I really can't quite imagine why.
> > 
> > That's all nice and clean in theory, but it was more or less the same 
> > reasoning as what was behind the tightening not to allow anything but 
> > refs/heads pointed by HEAD, but you know what fell out of it.  
> > "Insane" and "crap" are in the eye of the beholder.
> 
> I think there's no possible use to being able to use update-ref to 
> create a ref that rev-parse can't be made to read. I think people will 
> want to do all sorts of things that are insane (I'd personally like some 
> refs with the basename "..."), but they're only likely to do insane 
> things that happen to work, rather than insane things that aren't 
> prevented but still don't work.

Of course, you are forgetting that rev-parse may well have been able to 
grok such a ref at some stage.

And at that stage, it becomes not a user error, but a _huge_ mistake by 
us, the Git developers.

Don't blame the user 
(http://www.schneier.com/blog/archives/2009/03/it_security_bla.html).

Ciao,
Dscho