Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes:
> Hmm... well, it works great as long as you remember to always use
> --rebase-merges. The moment you forget to pass -r to "git rebase", your cover
> letter commit disappears, and I'm not sure this is going to work for what I am
> trying to do (which is to make the process of submitting patch series
> simpler). I know it's possible to configure git so that "git pull --rebase"
> preserves merges, but there doesn't appear to be a way to force "git rebase
> -i" to do the same without the -r flag. Also, "rebase -ir" looks really
> different when there is a tip merge commit, which will probably also be
> confusing to newbies just starting out with rebase workflows.
>
> So, I'm not sure that at this time this is objectively "better" than keeping
> the cover letter in an empty commit at the start of the series. :-/
Now you are discussing this on the git mailing list, you do not
necessarily have to take the existing behaviour of Git as given.
For example, I do not think it is unreasonable to teach "git rebase
[-i]" to special case a certain merge commit in the rebased range
without any extra option, as long as the criteria to pick such a
special "merge" is specific and narrow enough (a two-parent merge M
whose tree matches that of one parent's tree (say M^1^{tree}), the
other parent (say M^2) is an immediate ancestor of the bottommost
commit of the range being rebased, or something like that). And the
way you "special case" it does not have to be tied to the way the
"-r" option handles it, either.
A possible design could go like this:
* we recognize such a special merge commit;
* we rebase the rest of the range, pretending as if that merge
commit did not exist and instead its children are all direct
child of one of its parent (say M^1), using the options given (so
"-r" would affect how other merges in the rebased range is
handled).
* after everything is done, we create a new empty merge commit at
the top, merging the bottom of the range and the tip of the range
as its parents, using the log message from original M. This can
be done totally outside of the regular "rebase" machinery.
Such a change to existing behaviour is well within the scope of
"On-branch topic description support", I would think.
