Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 28, 2011, 00:32 UTC
Message-ID: <7vpqiltsky.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110927233549.GA10434@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 20 quoted lines

> On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote:
>
>>   With "git commit --no-parent", you would be altering the current
>>   branch head, which means you are potentially leaving as a dangling
>>   commit the commit to which that branch head originally pointed.
>>   I.e., it is about as dangerous as "git reset --hard <new_root_commit>",
>>   something for which we do NOT provide any protection.
>
> Didn't I already mention that example? And then say that I think the
> lack of protection there has been the source of a lot of confusion and
> hardship?
>
> Repeating the problems of "git reset" does not seem like a good idea to
> me. Especially not with a command like "commit", which is usually very
> safe.
>
> That being said, I did say in my last email that one option would be for
> the documentation to be very clear about leaving the old history
> dangling. That at least keeps clueless people from stumbling into using
> the option accidentally.

Both of you are right and I agree "commit --root" is a bad idea (I can change my mind ;-). Especially it is rare (and I would even say it should be discouraged) to create a new root commit in a repository that already has history, we should try to make it _very_ hard to lose history by mistake, even though that means creating a new root commit has to be done as a multi-step process (e.g. "checkout --orphan" to dissociate the new state from the current history and then "commit").

Thanks for a bit of sanity.