Re: [PATCH v3] git checkout -b: unparent the new branch with -o

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 17, 2010, 06:40 UTC
Message-ID: <20100317064034.GA31749@progeny.tock>
In-Reply-To: <7v4okfiksh.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 10 quoted lines

> 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