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

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

[Andreas Hennings]

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

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

[Junio C Hamano]

Andreas Hennings <andreas@dqxtech.net> writes:

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

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.

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

[Andreas Hennings]

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:
>
> Andreas Hennings <andreas@dqxtech.net> writes:
>
> > 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.
>
> 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.

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

[Andreas Hennings]

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:
>
> 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:
> >
> > Andreas Hennings <andreas@dqxtech.net> writes:
> >
> > > 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.
> >
> > 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.

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

[Junio C Hamano]

Andreas Hennings <andreas@dqxtech.net> writes:

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

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.