On Tue, Aug 27, 2019 at 07:47:33PM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Is this a good thing, though? > > > > Giving up (because you do not have enough time or concentration to > > finish the cherry-pick or revert in progress) with --abort, and > > committing to the resolution after spending effort to deal with a > > conflicted cherry-pick or revert with --continue, are both sensible > > actions after seeing the command stop due to conflicts. Is "--skip" > > a recommendable action in the same way? Doesn't a multi-commit > > series often break if you drop just one in the middle, especially > > if the series is sensibly structured as a logical progression? > > Addendum. > > "rebase" (especially with "-i") is fundamentally different from > "cherry-pick" and it makes tons of sense to suggest "--skip" in the > former. "rebase -i" is a tool to take a messy work in progress and > polish it by reordering, discarding and combining commits. > "cherry-pick" is to take a finished work already in one integration > track, and transplant to another, often an older maintenance track, > and there is no place for "this conflict is too much to resolve so > let's drop it". > I still believe that it's a good idea to let users know what all of their options are, including the --skip for cherry-pick and revert even if it may be rare that it's the right thing to do. That being said, I'm not passionate enough about this change to pursue it so when you queue this patchset, please drop this patch.
