Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > > > Junio was discussing the case B. > > Well, not really. Even as an ingredient, "nuke index, leaving files in > the work tree around" is the most difficult-to-use mode of operation. > Either "try to run 'git rm -f .' from the toplevel and only if it succeeds > point HEAD to an unborn branch" (aka "remove both"), or "point HEAD to an > unborn branch without doing anything else" (aka "keep both") would be an > ingredient that is far easier to use. Okay, fair enough. From the point of view of plumbing, what is there left to do that git rm -f . && git symbolic-ref HEAD refs/heads/new or git symbolic-ref HEAD refs/heads/new or git rm --cached . && git symbolic-ref HEAD refs/heads/new does not take care of? I guess I should have said that I would be happier to see something tailored to a use case or a class of use cases. I haven’t needed it for a while, but once upon a time I was making isolated branches like crazy for some abuse of git as a compression tool. Jonathan -- 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