Re: [PATCH] rebase: convert revert to squash on autosquash

["Michael S. Tsirkin" <mst@redhat.com>]

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.
> 
> 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

Sounds rather cool. Or alternatively

git revert --squash deadbeef