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

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.

So I'm not saying "we can't do this". I'm saying "this is dangerous, so
let's think for a minute about what safety mechanisms we can have".

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.

It's explicit if you understand how git works, or what "parent" means.
I'm not sure every git user does, these days.

-Peff