From: Michael Witten <mfwitten@gmail.com>
Date: Tue, 27 Sep 2011 23:28:14 GMT
Subject: Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
Message-ID: <CAMOZ1BvzWDPQ_e3Y5H8CX4wQwL5xf3xVvZvRL3gQPcB_kCGBbw@mail.gmail.com>
In-Reply-To: <20110927214213.GC5176@sigill.intra.peff.net>

On Tue, Sep 27, 2011 at 21:42, Jeff King <peff@peff.net> 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.