On Thu, Jul 21, 2022 at 01:01:16PM -0700, Junio C Hamano wrote:
> Now you are discussing this on the git mailing list, you do not
> necessarily have to take the existing behaviour of Git as given.
Indeed, I was mostly observing about how it works right now -- please don't
take this as complaining. :)
> 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.
I agree, this would be great. If this is in place, then it would certainly
bring us closer to managing "proposed change" series completely in-git.
One thought that comes to mind -- perhaps it would be easier not to track the
special commit, but designate the branch as a special "proposed changes"
branch that could even "hide" the cover-letter merge commit (CLM) from most
operations. It's still a simple two-parent merge commit, so it can be
pushed/pulled with any existing remotes without requiring any changes on the
server side, but operations like adding a regular new commit to the tip of
the "proposed changes" branch would automatically move the merge commit so
it's back at the tip. This way "not sure what you're trying to do" situations
like this would be avoided:
A--B--C--CLM--D--E
/ /
Y-----------
-K
