Feature request: --preserve-merges to add "exec git merge ..." instead of "pick ..."

Hello, (this is my first message on this list, so hello everybody. I hope I found the correct channel.)

I recently discovered the --preserve-merges option in git rebase, I think it is nice, but it does not always do what I intend.

I am proposing a variation of this option which would behave differently.

## Use case

We have an acceptance branch that is frequently rebased on master. At any given time, the acceptance branch should start with master, and then merge in those feature branches that were selected for acceptance testing. Nobody is supposed to work on acceptance, it is only meant for deployment on the acceptance server.

This means we need a rebase operation where:
- The commits of the acceptance branch itself are being replaced.
- The commits of the feature branches remain as they are.

A "git rebase --preserve-merges" almost does this, but not really.

## Proposal

Add a new option for rebase, similar to --preserve-merges, where: Instead of "git pick MERGE_COMMIT", we get this line in the rebase editor (if using the -i option): exec git merge MERGE_COMMIT^2 -m"Merge FEATURE_BRANCH into acceptance."

In --interactive / -i mode, the developer can leave these lines as they are, or replace them manually to merge a more recent version of the feature branch. E.g. replace this exec git merge MERGE_COMMIT^2 -m"Merge FEATURE_BRANCH into acceptance." with this exec git merge FEATURE_BRANCH_RECENT

This would achieve the behavior as described in "Use case". I have not thought about a name for this option yet, I first want to see some general feedback.

Possibly related: https://public-inbox.org/git/87y3jtqdyg.fsf@javad.com/ I think the author of this RFC has different expectations what a rebase should do, so it is not really the same.

------------

I hope this was the correct way to propose this kind of feature. If not, let me know where I can find more information.

Greetings, Andreas Hennings https://github.com/donquixote

Andreas Hennings <andreas@dqxtech.net> writes:

This wished-for feature sounds to me more like the "first-parent" mode that has been discussed a few times in the past but never materialized.

The preserve-merges mode is getting abandoned by the original author as unsalvageable. Have you tried the rebase-merges mode? That may let you choose replaying only the merge commits on the acceptance branch without touching the tips of the feature branches getting merged.

It sounds good! I was using git version 2.7.4 all the time. I should have checked before posting here :) Now trying 2.20.1

From "git help rebase":

           By default, or when no-rebase-cousins was specified,
commits which do not have <upstream> as direct ancestor will keep
their
           original branch point, i.e. commits that would be excluded
by gitlink:git-log[1]'s --ancestry-path option will keep their
           original ancestry by default. If the rebase-cousins mode is
turned on, such commits are instead rebased onto <upstream> (or
           <onto>, if specified).

I am not sure if this criterion (which ancestors it has) will always produce the behavior I am looking for. I will have to experiment a bit.

Thanks for now, I will post again with new thoughts once I have done some experiments.

On Mon, 7 Jan 2019 at 17:42, Junio C Hamano <gitster@pobox.com> wrote:

I tried this option after upgrading my git. Unfortunately, no matter which variation I use, it still attempts to rebase most or all of the feature branches before merging them. Possibly depending on their ancestry.

On Mon, 7 Jan 2019 at 22:12, Andreas Hennings <andreas@dqxtech.net> wrote:

Andreas Hennings <andreas@dqxtech.net> writes:

Yes, I know that. But what I am hoping is that it won't actually touch the commits on the side branches UNLESS you tell in the insn sequence to modify them with "edit", "reword", etc. and instead fast-forward them.

Of course, it will allow you to muck with these commits on the side branches, which is a potential source of mistakes.