Jeff King <peff@xxxxxxxx> writes: > On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote: > >> 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. > > Didn't I already mention that example? And then say that I think the > lack of protection there has been the source of a lot of confusion and > hardship? > > Repeating the problems of "git reset" does not seem like a good idea to > me. Especially not with a command like "commit", which is usually very > safe. > > That being said, I did say in my last email that one option would be for > the documentation to be very clear about leaving the old history > dangling. That at least keeps clueless people from stumbling into using > the option accidentally. Both of you are right and I agree "commit --root" is a bad idea (I can change my mind ;-). Especially it is rare (and I would even say it should be discouraged) to create a new root commit in a repository that already has history, we should try to make it _very_ hard to lose history by mistake, even though that means creating a new root commit has to be done as a multi-step process (e.g. "checkout --orphan" to dissociate the new state from the current history and then "commit"). Thanks for a bit of sanity. -- 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