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

Jeff King [off-list ref] writes:

On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote:

quoted

  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.