I’m a little surprised that it’s almost 2016 and I still haven’t seen a VCS where reverting a commit is integral to the workflow, works in a distributed environment, and doesn’t screw everyone up (but I haven’t used hg much, does that do it cleanly?). I’d like to see a commit log that shows a commit, shows that it was reverted, and doesn’t need to be committed in a completely manual fashion.
If you can compromise on the distributed part, that’s basically how it works in svn. :) If you do an svn merge -c -NNN ., commit NNN will be reverted, but both the commit and the revert will still show up in the log.
The “fixup” option does the same thing as the “squash” option the author uses, but it does the second step of removing the useless commit message for you.
I’m a little surprised that it’s almost 2016 and I still haven’t seen a VCS where reverting a commit is integral to the workflow, works in a distributed environment, and doesn’t screw everyone up (but I haven’t used hg much, does that do it cleanly?). I’d like to see a commit log that shows a commit, shows that it was reverted, and doesn’t need to be committed in a completely manual fashion.
If you can compromise on the distributed part, that’s basically how it works in svn. :) If you do an
svn merge -c -NNN ., commit NNN will be reverted, but both the commit and the revert will still show up in the log.That’s more or less precisely what Mercurial Evolve is – collaborative undoing. It adds a meta-history that says which commit replaces which other.
I wrote a similar post in July 2014 - http://www.tablexi.com/2014/07/rewriting-git-history/developers/ - I liked this write-up though.
The “fixup” option does the same thing as the “squash” option the author uses, but it does the second step of removing the useless commit message for you.