Re: Reverting a range of commits with conflict

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sam Lee <skynare@xxxxxxxxx> writes:

> It brings up EDITOR twice and I end up with two commits.
> I can squash them. But, I don't know if this is a desired behavior.

It is my understanding that the users who do want a single revert of
multiple commits are expected to squash them (by choosing which ones
to squash into one), so if you really want to make them into one,
you can squash them and that is your desired behaviour.  The point
is that you do not have to.

If you think a bit about it, it does not make much sense to leave
outstanding changes in limbo with --no-commit when you are picking
or reverting multiple commits.  The first one may replay cleanly or
may not and needs manual resolution, but after that, the work you
did will only be in your working tree, and the difference between
that and the HEAD and the index is not recorded anywhere else.  What
happens when the replaying (either cherry-picking or reverting) of
the second one had conflict?  The effect of picking or reverting the
first one is now intermingled with the effect of the conflicted
picking or reverting of the second---with --no-commit, the workflow
is making the messy conflicted state needlessly larger.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux