From: Jonathan Nieder <jrnieder@gmail.com>
Date: Wed, 17 Mar 2010 06:40:34 GMT
Subject: Re: [PATCH v3] git checkout -b: unparent the new branch with -o
Message-ID: <20100317064034.GA31749@progeny.tock>
In-Reply-To: <7v4okfiksh.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> 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