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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html