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. So I'm not saying "we can't do this". I'm saying "this is dangerous, so let's think for a minute about what safety mechanisms we can have". > 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. It's explicit if you understand how git works, or what "parent" means. I'm not sure every git user does, these days. -Peff -- 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