On Fri, Apr 08, 2016 at 01:13:51PM +0200, Johannes Schindelin wrote:
Show 46 quoted lines
> 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