Re: On-branch topic description support?

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 21, 2022, 20:01 UTC
Message-ID: <xmqqa692grqr.fsf@gitster.g>
In-Reply-To: <20220721191349.kf3zx4tpwrjhzudt@nitro.local>

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

Show 12 quoted lines

> 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.