Re: Feature request: --preserve-merges to add "exec git merge ..." instead of "pick ..."
- From
- Andreas Hennings <andreas@dqxtech.net>
- Date
- Jan 8, 2019, 18:13 UTC
- Message-ID
- <CAH0Uv3F4q0oPG2O58eTV5n+5eZcxHK9acGMX+4F4LTm1JATfhg@mail.gmail.com>
- In-Reply-To
- <CAH0Uv3FRq0JiXWx9Ow1EhKrYB4OTM-9Fpox7FvZ3tC6J6toEsw@mail.gmail.com>
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:
Show 43 quoted lines
> > 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.