Hi Junio, [It's been a while since this discussion, and recently I've got some thoughts and questions about "first-parent" issues in general, below.] 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. > > Allowing "-m1" even when picking a single parent commit, because > the 1-st parent is defined for such a commit, makes sense, espeially > when running a cherry-pick on a range, exactly for the above reason. > It is slightly less so when cherry-picking a single commit, but not > by a large margin. > > I think the original reasoning for requiring "-m $n" not present, > especially because cherry-pick was originally for replaying only a > single commit, was because it would lead somebody to propose that > the command should behave as if -m1 is always given (and when trying > to cherry-pick a merge relative to its second parent, give -m2 to > override it), which in turn encourage the 'first-parent is special' > world-view from the tool-side. IOW, "The worldview to treat the > first-parent chain specially is correct, because Git has many > features to work with that worldview conveniently" was something we > wanted to avoid; rather "Such and such workflows benefit from > treating the first-parent chain specially, so let's add features to > do so" was we wanted to do, and of course, back then cherry-pick > that allows mixture of merges and single-parent commits to be > picked, which would have made the need to do something like this > patch does felt greater, did not exist. > > Now, it appears, at least to me, that the world pretty much accepted > that the first-parent worldview is often very convenient and worth > supporting by the tool, so the next logical step might be to set > opts->mainline to 1 by default (and allow an explicit "-m $n" from > the command line to override it). But that should happen after this > patch lands---it is logically a separate step, I would think. I think that "first-parent is special" is the way to go indeed for porcelain, as it does make many thing easier and more convenient[*]. Is there a road-map already outlined in that direction, I wonder? OTOH, for plumbing, it's rather keeping the original pure-DAG "symmetrical merges" approach that seems to be the right thing to do. [*] One example that immediately comes to mind is "git log -p" for a merge commit. I doesn't currently (as of v2.10) show the first-parent diff, for whatever reason. "git log -p -m --first-parent" is needed to get the answer to most "obvious" question: what (merge) commit did to my mainline? "git show" has its own issues. -- Sergey
