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

From: Junio C Hamano <[email-masked]>
Date: Tue, 27 Sep 2011 17:32:13 -0700

Jeff King <[email-masked]> writes:

> 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.