Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >> When cherry-picking multiple commits, it's impossible to have both >> merge- and non-merge commits on the same command-line. Not specifying >> '-m 1' results in cherry-pick refusing to handle merge commits, while >> specifying '-m 1' fails on non-merge commits. >> >> This patch allows '-m 1' for non-merge commits. Besides, as mainline is >> always the only parent for a non-merge commit, it made little sense to >> disable it in the first place. > > In the original context to pick a single commit, it made perfect > sense to avoid mistakes by blindly passing '-m 1' to non-merge > commit. > > It may be fair to say that we failed to reconsider what to > do with '-m 1' when we did 7e2bfd3f, but it is utterly an unfair > history revisionism to say that it made little sense to disable it > in the first place. In fact I had zero intention on any revisionism. Now I see I should have said "makes little sense" in present tense to avoid touching deep historical issues, sorry! Something like: "This patch allows '-m 1' for non-merge commits. As mainline is always the only parent for a non-merge commit, it makes little sense to disable it." sounds OK? > > The change to the code itself looks sane, but applying this patch > alone will break existing tests whose expectations must be updated, > and this new behaviour must be protected by a new test (or two) so > that we won't accidentally stop accepting "-m 1" for a single-parent > commit. I fixed most of the tests, but "t3510/4: cherry-pick persists opts correctly" is an offender for me. It looks like it [ab]uses current "-m 1" behavior just to stop in the middle of the sequence, and I'm not sure how to fix it most suitably. Thanks! -- Sergey
