Hi, On Wed, 14 Oct 2009, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxxxxxx> writes: > > > Can't the user confusion be dealt with through some means other than > > making the tool less flexible? I don't mind extra help message to be > > displayed after a headless commit is made for example. But trying to > > make the tool more friendly should perhaps come from better education > > rather than added restrictions. > > > > My thoughts only. > > I actually share that but there apparently are people who have given up on > the education route. At some point, when you try to teach something that people (i.e. more than one person) do not get easily, you cannot do anything but admit that what you try to teach is crap. Obviously you did not have that experience. Maybe you are just more picky than me when it comes to who you try to teach. But of course, that does not make what you try to teach less crap. In this particular case, I cannot help but notice that commits performed on a detached HEAD will get lost _unless_ they are somehow put onto a named branch eventually. So the only question is whether you restrict flexibility by requiring to name the branch first before committing, instead of committing and then naming the branch. So you are talking about "retaining flexibility" in favor of making the tool less user-friendly, when all it would take from the few power-users is to name the branch before committing to it, instead of the other way round. You must be kidding me. 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