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