On Fri, Apr 08, 2016 at 01:13:51PM +0200, Johannes Schindelin wrote: > 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.
Well then you have to decide whether you want to drop it when you commit. If *I* want do drop the patch when I commit, I just do git rebase. > 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 Maybe but it's a different usecase. What this addresses is a case where you first wanted to avoid rebases, so you reverted. But then you rebased after all. Now finding what was reverted automatically is helpful. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
