Hi Michael, On Thu, 7 Apr 2016, Michael S. Tsirkin wrote: > On Thu, Apr 07, 2016 at 05:23:09PM +0200, Johannes Schindelin wrote: > > > > On Thu, 7 Apr 2016, Michael S. Tsirkin wrote: > > > > > Reverts can typically be treated like squash. Eliminating both the > > > original commit and the revert would be even nicer, but this seems a bit > > > harder to implement. > > > > Whoa. This rings a lot of alarm bells, very loudly. > > Whoa don't be alarmed. It's just a patch :). It's just a patch. Like every major breakage would be. So: no, there is reason to be alarmed if it is likely to disrupt normal usage. > > It seems you intend to introduce a *major* change in behavior, > > Doing this automatically for all users might be a bit too drastic for > the upstream git. That is a pretty safe thing to say, even without the subjunctive. > If there's a commit later followed by a revert, history can be > simplified by squashing them, and if the result is empty, removing both. True. But that is not what the user told Git to do. If the user's intention was to squash the reverting patch, she could have easily done this: git revert -n deadbeef git commit --squash deadbeef where "deadbeef" is the placeholder for the actual commit to revert. And indeed, I use exactly this song and dance quite frequently, *iff* my intention is to drop a patch. A much better idea than co-opting the "Revert" commit message would be to introduce a sibling to --fixup and --squash that you could call --drop. Ciao, Johannes -- 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