From: Jeff King Date: Tue, 27 Sep 2011 21:42:13 GMT Subject: Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head' Message-ID: <20110927214213.GC5176@sigill.intra.peff.net> In-Reply-To: On Tue, Sep 27, 2011 at 10:31:17PM +0100, Philip Oakley wrote: > >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.