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

From: Jeff King <peff@peff.net>
Date: Sep 27, 2011, 21:42 UTC
Message-ID: <20110927214213.GC5176@sigill.intra.peff.net>
In-Reply-To: <DBCBE20265964ECCA5B9724DAC74D83B@PhilipOakley>

On Tue, Sep 27, 2011 at 10:31:17PM +0100, Philip Oakley wrote:

Show 13 quoted lines

> >Not this person.
> >
> >I like the idea but I'd rather see:
> >
> >git commit --no-parent
> >
> >"parent" at least appears in gitk and therefore newcomers will prob
> >have a better chance of understanding the intent w/out needing to
> >otherwise unnecessary terminology.
> >--
> I think this feels and sounds sensible.  And better located within
> the 'commit' command, rather than 'checkout --orphan' which was more
> obscure (and difficult to find).

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

So at the very least, the documentation for the new option would need to make the consequences very clear, and that one should run it on a newly created branch if they don't want to throw away the old history.

-Peff

[1] Actually, it's similarly dangerous to "git reset", which doesn't
    have a force flag. But then, "git reset" is frequently brought up as
    the most dangerous and confusing command by new git users.