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

On Tue, Sep 27, 2011 at 21:42, Jeff King [off-list ref] wrote:

Keep in mind that making it part of commit is potentially much more
dangerous. With "checkout --orphan", you are making a _new_ branch that
has no parents. Committing on it will make a disconnected history, but
your original branch is still there.

With "git commit --no-parent", you are disconnecting history on the
_current_ branch. Which means you are throwing away the old history
completely. I.e., it is about as dangerous as "git branch -d", which we
usually protect with a "force" flag[1].

If I might be a bit more pedantic:

  With "checkout --orphan", you are setting up a new branch head
  to point to an as-yet-to-exist commit that will have no parents.
  Your original branch head is not changed.

  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.

For instance, what if I want the current branch head to point to that
new root commit? The existing solution requires juggling branch names;
why can't git just do what I tell it to do (as with "git reset")?
After all, "git commit --no-parent" is pretty name explicit.