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

[Philip Oakley <philipoakley@iee.email>]

Hi Joel,

On 24/03/2022 13:42, Johannes Schindelin wrote:
> Hi Joel,
>
> please reply inline. What you did is called "top-posting" on this list and
> is regularly discouraged.
>
> On Tue, 22 Mar 2022, Joel Marshall wrote:
>
>> I have confirmed that this is still an issue under certain
>> circumstances. --rebase-merges works as expected if it is being used
>> with simple feature branches, ie one commit after the other, no
>> merges. Where things go off of the rails is when there are branches
>> and merges coming off of and going into a feature branch. At that
>> point using the --rebase-merges flag with rebase will create a similar
>> mess to the images of the logs I attached back in July of 2022.
> I wonder what happened to my suggestions to use
> `--rebase-merges=rebase-cousins` or `git fast-export --anonymize`. They
> seem to have faded without any echo.
>
> Ciao,
> Johannes
>

The rebasing of merges can be confusing, with the different perspectives 
(mental models) about which line of development the merges arrive from.

In support of Johannes' note, the stack overflow Q&A [1] does contain 
some nice diagrams showing the different ways that a history can be 
interpreted, and the effect that "cousins" have on the picture 
(understanding not helped by many colloquial familial uses of 'cousins' 
that are not technically correct ;-).

Your case of two parallel lines of development, with merges from one to 
the other, being rebased from the original fork-point, does look to fit 
that 'difference of mental model' confusion.

Does that SO Q&A help clarify the situation. If you are able to create a 
similar simplified hierarchy (e.g. cut out the long linear sections) of 
your scenario then it becomes easier to help.

Philip
[1] 
https://stackoverflow.com/questions/56529435/what-is-the-behavior-of-the-cousins-options-in-git-rebase-rebase-merges
>> On Wed, Dec 8, 2021 at 3:46 PM Joel Marshall <joelmdev@gmail.com> wrote:
>>> Hi all,
>>>
>>> Sorry to drop off on this for so long. I think this is still a
>>> possible outstanding issue, yes? If so I will work on getting you a
>>> copy of the repo as I did archive a copy at the state originally
>>> mentioned in this issue.
>>>
>>> On Mon, Aug 10, 2020 at 10:46 AM Johannes Schindelin
>>> <Johannes.Schindelin@gmx.de> wrote:
>>>> Hi Joel,
>>>>
>>>> On Thu, 23 Jul 2020, Joel Marshall wrote:
>>>>
>>>>> I saved the state of the repo in a copy so I could come back to it if
>>>>> additional examples were needed but I had to clean up my live copy so
>>>>> I could get back to work. I'll get you some additional screenshots in
>>>>> the next few days. In the meantime, I'll try to give you some context
>>>>> around what I'm doing here. The parent branch is my main dev branch
>>>>> which consists of a series of clean branches and merges- the dev
>>>>> branch basically looks like what you're seeing in the
>>>>> --preserve-merges screenshot. I've also got a long running feature
>>>>> branch that branches off of dev, and it also consists of many branches
>>>>> and merges, each a subtask of the story related to the feature branch
>>>>> as a whole. Occasionally to get the feature branch up to date with the
>>>>> newest features I'll rebase the whole thing on top of dev, which
>>>>> should result in an unbroken chain of branches and merges as seen in
>>>>> the --preserve-merges screenshot. While you can't see it in the
>>>>> --rebase-merges screenshot, those merges show no ancestors when viewed
>>>>> in reverse chronological order- they just trail off into oblivion.
>>>> I could imagine that you might want to try this rebase with
>>>> `--rebase-merges=rebase-cousins`.
>>>>
>>>> Otherwise, you might want to export your use case with `git fast-export
>>>> --anonymize` so that others (such as myself) have a chance of helping you.
>>>>
>>>> Ciao,
>>>> Johannes