Re: Possible issue with rebase's --rebase-merges option

> I've attached a couple of screenshots from tortoisegit. The branches
> are too long to show in their entirety, but this should give you an
> idea of what I'm talking about. The highlighted commit is the head of
> the branch that I'm rebasing onto. Interestingly, I just noticed that
> while --rebase merges reports that it's rebasing 202 commits
> intitially, upon manually reconciling the first conflict it reports
> that it is rebasing 183 commits.

> On Wed, Jul 22, 2020 at 10:22 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>> Hi Joel
>>
>> On 21/07/2020 22:20, Joel Marshall wrote:
>>> Thank you for filling out a Git bug report!
>>> Please answer the following questions to help us understand your issue.
>>>
>>> What did you do before the bug happened? (Steps to reproduce your issue)
>>> This is a difficult one to give proper steps to reproduce. The issue
>>> is with rebase's --rebase-merges flag. We recently switched from using
>>> rebase with the --preserve-merges option to --rebase-merges. Most of
>>> the time the output is the same, but sometimes it is very different.
>>> I'm unable to determine whether this is by design or a bug.
>>
>> --preserve-merges is buggy if you rearrange the commits (this is way
>> --rebase-merges was added), if you're just rebasing without reordering
>> anything then I think the result should be the same though there may be
>> some corner cases I'm not aware of. Are you able to share the topology
>> before rebasing and after with --preserve-merges and --rebase-merges?
>>
>>> What did you expect to happen? (Expected behavior)
>>> Resulting graph after running rebase --rebase-merges is the same as
>>> running rebase --preserve-merges.
>>>
>>> What happened instead? (Actual behavior)
>>> Using --rebase merges tries to pick substantially more commits and
>>> results in merge commits with no parent commit when viewing log in
>>> reverse chronological order.
>>>
>>> What's different between what you expected and what actually happened?
>>> When the issue does occur (it doesn't for all rebases) it results in
>>> two completely different logs and picks commits that are apparently
>>> not part of the branch being rebased. eg, for a branch with 128
>>> commits including merges, --preserve-merges picks 128 commits and the
>>> resulting topology matches the original branch's topology.
>>> --rebase-merges picked 183(?) commits in v2.24 and 202 commits in
>>> v2.27, and in both cases resulted in a very strange topology.
>>
>> That's interesting there were some changes to how empty commits and
>> upstreamed commits are handled between v2.24 and v2.17, without seeing
>> the staring point and the results it's hard to tell what is going on though.
>>
>> Without seeing some examples it's hard to tell if there is a bug here or
>> not though it does sound a bit suspicious.
>>
>>> Anything else you want to add:
>>> Feel free to contact me at joel@tusksoft.com for additional details.
>>
>> You email me directly if there are things you don't want to share on the
>> list
>>
>> Best wishes
>>
>> Phillip
>>
>>> I
>>> would love to understand if this is by design or a legitimate bug.
>>>
>>> Please review the rest of the bug report below.
>>> You can delete any lines you don't wish to share.
>>>
>>>
>>> [System Info]
>>> git version:
>>> git version 2.27.0.windows.1
>>> cpu: x86_64
>>> built from commit: 907ab1011dce9112700498e034b974ba60f8b407
>>> sizeof-long: 4
>>> sizeof-size_t: 8
>>> uname: Windows 10.0 18363
>>> compiler info: gnuc: 10.1
>>> libc info: no libc information available
>>>
>>>
>>> [Enabled Hooks]
>>>