Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >>> The same effect can be had by just reverting "let's allow -m1 for >>> single-parent commit", can't it? That is a far simpler solution, I >>> would say. >> >> Those one didn't introduce the issue currently at hand, as we still >> don't allow merges by default, so why do we need to rewind it? > > With it reverted, "[alias] cp = cherry-pick -m1" can be used to train > the user to blindly pick a range that has a merge without thinking, > which is what I meant by "ship has already sailed". Did you mean "With it *not* reverted" here? Because with it reverted, "cherry-pick -m1" will rather loudly fail on the first non-merge commit in the range. Such alias would be useless without that patch. Those who don't like such alias are still free not to define or use it. > With it reverted, a range pick of a straight single strand of pearls > would still work just fine. And the user is forced to think and > chop a range with a merge into a set of subranges each of which is a > single strand of pearls, plus picking individual merges (if picking > these merges is really what the user wants, that is). Unfortunately, this gets us back to the exact problem with practical use-case the patch was provoked by. There was a large number of commits to be picked, and the set has been carefully built by "git rev-list" (as "git cherry-pick" built-in features were not enough: yet another issue). Some of these commits were merges, and handling all this manually (and repeatedly) would be a real pain. It was easier to locally patch "git cherry-pick -m1" to achieve the goal. Then I thought that it could help others in the future, and then took time to provide the patch. It'd be a real pity to get back to where I started. BTW, the above also shows that the issue with "-m 1" existed even before "git cherry-pick" started to accept ranges, as I was not using these ranges anyway. Overall, I mean that I still need a way to tell "git cherry-pick" that I do know what I'm doing, so that it stops complaining on a non-issue. Thus if the patch is reverted, a new option should be added just for this goal, -- back to where we are now, but an option already added. > As ensuring the users to think is the whole point of excercise, Yeah, provided they do have a suitable way out. Without that patch, there was none. > the original system before we allowed "-m1" for single parent commit > was after all giving us the right balance, I guess, without having to > add yet another new option. No, unfortunately it didn't, and to me the patch in question still seems to be in the right direction, legitimate, and useful. Moreover, I still can't see how it's harmful. Just don't use '-m 1' if you don't want merges. -- Sergey
