Hi, On Fri, 20 Mar 2009, Daniel Barkalow wrote: > On Fri, 20 Mar 2009, Junio C Hamano wrote: > > > Petr Baudis <pasky@xxxxxxx> 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 -- 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
