{"thread":{"id":"53896","subject":"Possible issue with rebase's --rebase-merges option","startedAt":"2020-07-21T21:21:10Z","lastAt":"2022-03-28T11:24:24Z","messageCount":10,"participants":["Joel Marshall","Phillip Wood","Johannes Schindelin","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"401826","messageId":"CAK1xKQpUFCkv6fopEykKLxAEoG_Hf_Zz+oRR70mR3pWsN5YDDw@mail.gmail.com","threadId":"53896","inReplyTo":null,"subject":"Possible issue with rebase's --rebase-merges option","fromName":"Joel Marshall","fromEmail":"joelmdev@gmail.com","sentAt":"2020-07-21T21:20:49Z","receivedAt":"2020-07-21T21:21:10Z","isPatch":false,"sender":{"key":"joelmdev@gmail.com","avatar":"https://gravatar.com/avatar/b4fdc9936cac61479f181b58d8a33552c36e06f4f2ea7f0361431daa6d50e1d4?d=mp&s=160"},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\nThis is a difficult one to give proper steps to reproduce. The issue\nis with rebase's --rebase-merges flag. We recently switched from using\nrebase with the --preserve-merges option to --rebase-merges. Most of\nthe time the output is the same, but sometimes it is very different.\nI'm unable to determine whether this is by design or a bug.\n\nWhat did you expect to happen? (Expected behavior)\nResulting graph after running rebase --rebase-merges is the same as\nrunning rebase --preserve-merges.\n\nWhat happened instead? (Actual behavior)\nUsing --rebase merges tries to pick substantially more commits and\nresults in merge commits with no parent commit when viewing log in\nreverse chronological order.\n\nWhat's different between what you expected and what actually happened?\nWhen the issue does occur (it doesn't for all rebases) it results in\ntwo completely different logs and picks commits that are apparently\nnot part of the branch being rebased. eg, for a branch with 128\ncommits including merges, --preserve-merges picks 128 commits and the\nresulting topology matches the original branch's topology.\n--rebase-merges picked 183(?) commits in v2.24 and 202 commits in\nv2.27, and in both cases resulted in a very strange topology.\n\nAnything else you want to add:\nFeel free to contact me at joel@tusksoft.com for additional details. I\nwould love to understand if this is by design or a legitimate bug.\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.27.0.windows.1\ncpu: x86_64\nbuilt from commit: 907ab1011dce9112700498e034b974ba60f8b407\nsizeof-long: 4\nsizeof-size_t: 8\nuname: Windows 10.0 18363\ncompiler info: gnuc: 10.1\nlibc info: no libc information available\n\n\n[Enabled Hooks]\n"},{"id":"401846","messageId":"ac3a5871-b009-f84e-d1fe-af4bde1bbabe@gmail.com","threadId":"53896","inReplyTo":"CAK1xKQpUFCkv6fopEykKLxAEoG_Hf_Zz+oRR70mR3pWsN5YDDw@mail.gmail.com","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-07-22T14:22:48Z","receivedAt":"2020-07-22T14:22:54Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Joel\n\nOn 21/07/2020 22:20, Joel Marshall wrote:\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> This is a difficult one to give proper steps to reproduce. The issue\n> is with rebase's --rebase-merges flag. We recently switched from using\n> rebase with the --preserve-merges option to --rebase-merges. Most of\n> the time the output is the same, but sometimes it is very different.\n> I'm unable to determine whether this is by design or a bug.\n\n--preserve-merges is buggy if you rearrange the commits (this is way \n--rebase-merges was added), if you're just rebasing without reordering \nanything then I think the result should be the same though there may be \nsome corner cases I'm not aware of. Are you able to share the topology \nbefore rebasing and after with --preserve-merges and --rebase-merges?\n\n> What did you expect to happen? (Expected behavior)\n> Resulting graph after running rebase --rebase-merges is the same as\n> running rebase --preserve-merges.\n> \n> What happened instead? (Actual behavior)\n> Using --rebase merges tries to pick substantially more commits and\n> results in merge commits with no parent commit when viewing log in\n> reverse chronological order.\n> \n> What's different between what you expected and what actually happened?\n> When the issue does occur (it doesn't for all rebases) it results in\n> two completely different logs and picks commits that are apparently\n> not part of the branch being rebased. eg, for a branch with 128\n> commits including merges, --preserve-merges picks 128 commits and the\n> resulting topology matches the original branch's topology.\n> --rebase-merges picked 183(?) commits in v2.24 and 202 commits in\n> v2.27, and in both cases resulted in a very strange topology.\n\nThat's interesting there were some changes to how empty commits and \nupstreamed commits are handled between v2.24 and v2.17, without seeing \nthe staring point and the results it's hard to tell what is going on though.\n\nWithout seeing some examples it's hard to tell if there is a bug here or \nnot though it does sound a bit suspicious.\n\n> Anything else you want to add:\n> Feel free to contact me at joel@tusksoft.com for additional details.\n\nYou email me directly if there are things you don't want to share on the \nlist\n\nBest wishes\n\nPhillip\n\n> I\n> would love to understand if this is by design or a legitimate bug.\n> \n> Please review the rest of the bug report below.\n> You can delete any lines you don't wish to share.\n> \n> \n> [System Info]\n> git version:\n> git version 2.27.0.windows.1\n> cpu: x86_64\n> built from commit: 907ab1011dce9112700498e034b974ba60f8b407\n> sizeof-long: 4\n> sizeof-size_t: 8\n> uname: Windows 10.0 18363\n> compiler info: gnuc: 10.1\n> libc info: no libc information available\n> \n> \n> [Enabled Hooks]\n> \n"},{"id":"401847","messageId":"CAK1xKQr1_52n5rAhQh2awsb6SkgUYOMWoLichtBRLvtDXRQarQ@mail.gmail.com","threadId":"53896","inReplyTo":"ac3a5871-b009-f84e-d1fe-af4bde1bbabe@gmail.com","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Joel Marshall","fromEmail":"joelmdev@gmail.com","sentAt":"2020-07-22T17:09:28Z","receivedAt":"2020-07-22T17:09:50Z","isPatch":false,"sender":{"key":"joelmdev@gmail.com","avatar":"https://gravatar.com/avatar/b4fdc9936cac61479f181b58d8a33552c36e06f4f2ea7f0361431daa6d50e1d4?d=mp&s=160"},"body":"I've attached a couple of screenshots from tortoisegit. The branches\nare too long to show in their entirety, but this should give you an\nidea of what I'm talking about. The highlighted commit is the head of\nthe branch that I'm rebasing onto. Interestingly, I just noticed that\nwhile --rebase merges reports that it's rebasing 202 commits\nintitially, upon manually reconciling the first conflict it reports\nthat it is rebasing 183 commits.\n\n\nOn Wed, Jul 22, 2020 at 10:22 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>\n> Hi Joel\n>\n> On 21/07/2020 22:20, Joel Marshall wrote:\n> > Thank you for filling out a Git bug report!\n> > Please answer the following questions to help us understand your issue.\n> >\n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> > This is a difficult one to give proper steps to reproduce. The issue\n> > is with rebase's --rebase-merges flag. We recently switched from using\n> > rebase with the --preserve-merges option to --rebase-merges. Most of\n> > the time the output is the same, but sometimes it is very different.\n> > I'm unable to determine whether this is by design or a bug.\n>\n> --preserve-merges is buggy if you rearrange the commits (this is way\n> --rebase-merges was added), if you're just rebasing without reordering\n> anything then I think the result should be the same though there may be\n> some corner cases I'm not aware of. Are you able to share the topology\n> before rebasing and after with --preserve-merges and --rebase-merges?\n>\n> > What did you expect to happen? (Expected behavior)\n> > Resulting graph after running rebase --rebase-merges is the same as\n> > running rebase --preserve-merges.\n> >\n> > What happened instead? (Actual behavior)\n> > Using --rebase merges tries to pick substantially more commits and\n> > results in merge commits with no parent commit when viewing log in\n> > reverse chronological order.\n> >\n> > What's different between what you expected and what actually happened?\n> > When the issue does occur (it doesn't for all rebases) it results in\n> > two completely different logs and picks commits that are apparently\n> > not part of the branch being rebased. eg, for a branch with 128\n> > commits including merges, --preserve-merges picks 128 commits and the\n> > resulting topology matches the original branch's topology.\n> > --rebase-merges picked 183(?) commits in v2.24 and 202 commits in\n> > v2.27, and in both cases resulted in a very strange topology.\n>\n> That's interesting there were some changes to how empty commits and\n> upstreamed commits are handled between v2.24 and v2.17, without seeing\n> the staring point and the results it's hard to tell what is going on though.\n>\n> Without seeing some examples it's hard to tell if there is a bug here or\n> not though it does sound a bit suspicious.\n>\n> > Anything else you want to add:\n> > Feel free to contact me at joel@tusksoft.com for additional details.\n>\n> You email me directly if there are things you don't want to share on the\n> list\n>\n> Best wishes\n>\n> Phillip\n>\n> > I\n> > would love to understand if this is by design or a legitimate bug.\n> >\n> > Please review the rest of the bug report below.\n> > You can delete any lines you don't wish to share.\n> >\n> >\n> > [System Info]\n> > git version:\n> > git version 2.27.0.windows.1\n> > cpu: x86_64\n> > built from commit: 907ab1011dce9112700498e034b974ba60f8b407\n> > sizeof-long: 4\n> > sizeof-size_t: 8\n> > uname: Windows 10.0 18363\n> > compiler info: gnuc: 10.1\n> > libc info: no libc information available\n> >\n> >\n> > [Enabled Hooks]\n> >\n"},{"id":"401852","messageId":"fc38a32f-91e2-fe49-a7b0-e2e6851271c4@gmail.com","threadId":"53896","inReplyTo":"CAK1xKQr1_52n5rAhQh2awsb6SkgUYOMWoLichtBRLvtDXRQarQ@mail.gmail.com","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-07-22T18:30:50Z","receivedAt":"2020-07-22T18:31:00Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Joel\n\nOn 22/07/2020 18:09, Joel Marshall wrote:\n> I've attached a couple of screenshots from tortoisegit. The branches\n> are too long to show in their entirety, but this should give you an\n> idea of what I'm talking about. The highlighted commit is the head of\n> the branch that I'm rebasing onto. Interestingly, I just noticed that\n> while --rebase merges reports that it's rebasing 202 commits\n> intitially, upon manually reconciling the first conflict it reports\n> that it is rebasing 183 commits.\n\nThanks, the rebased topologies are certainly quite different, what is\nthe topology before the rebase? Looking at the --rebase-merges result it\nlooks like the second parents of merges that are being rebased have\nancestors in the upstream branch. If that is the case then I think it is\nworking as intended.\n\n Are you able to run\n\n  git log --format=%ad --graph $upstream..HEAD\n\nbefore and after the rebase to check that?\n\nBest Wishes\n\nPhillip\n\n> On Wed, Jul 22, 2020 at 10:22 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>>\n>> Hi Joel\n>>\n>> On 21/07/2020 22:20, Joel Marshall wrote:\n>>> Thank you for filling out a Git bug report!\n>>> Please answer the following questions to help us understand your issue.\n>>>\n>>> What did you do before the bug happened? (Steps to reproduce your issue)\n>>> This is a difficult one to give proper steps to reproduce. The issue\n>>> is with rebase's --rebase-merges flag. We recently switched from using\n>>> rebase with the --preserve-merges option to --rebase-merges. Most of\n>>> the time the output is the same, but sometimes it is very different.\n>>> I'm unable to determine whether this is by design or a bug.\n>>\n>> --preserve-merges is buggy if you rearrange the commits (this is way\n>> --rebase-merges was added), if you're just rebasing without reordering\n>> anything then I think the result should be the same though there may be\n>> some corner cases I'm not aware of. Are you able to share the topology\n>> before rebasing and after with --preserve-merges and --rebase-merges?\n>>\n>>> What did you expect to happen? (Expected behavior)\n>>> Resulting graph after running rebase --rebase-merges is the same as\n>>> running rebase --preserve-merges.\n>>>\n>>> What happened instead? (Actual behavior)\n>>> Using --rebase merges tries to pick substantially more commits and\n>>> results in merge commits with no parent commit when viewing log in\n>>> reverse chronological order.\n>>>\n>>> What's different between what you expected and what actually happened?\n>>> When the issue does occur (it doesn't for all rebases) it results in\n>>> two completely different logs and picks commits that are apparently\n>>> not part of the branch being rebased. eg, for a branch with 128\n>>> commits including merges, --preserve-merges picks 128 commits and the\n>>> resulting topology matches the original branch's topology.\n>>> --rebase-merges picked 183(?) commits in v2.24 and 202 commits in\n>>> v2.27, and in both cases resulted in a very strange topology.\n>>\n>> That's interesting there were some changes to how empty commits and\n>> upstreamed commits are handled between v2.24 and v2.17, without seeing\n>> the staring point and the results it's hard to tell what is going on though.\n>>\n>> Without seeing some examples it's hard to tell if there is a bug here or\n>> not though it does sound a bit suspicious.\n>>\n>>> Anything else you want to add:\n>>> Feel free to contact me at joel@tusksoft.com for additional details.\n>>\n>> You email me directly if there are things you don't want to share on the\n>> list\n>>\n>> Best wishes\n>>\n>> Phillip\n>>\n>>> I\n>>> would love to understand if this is by design or a legitimate bug.\n>>>\n>>> Please review the rest of the bug report below.\n>>> You can delete any lines you don't wish to share.\n>>>\n>>>\n>>> [System Info]\n>>> git version:\n>>> git version 2.27.0.windows.1\n>>> cpu: x86_64\n>>> built from commit: 907ab1011dce9112700498e034b974ba60f8b407\n>>> sizeof-long: 4\n>>> sizeof-size_t: 8\n>>> uname: Windows 10.0 18363\n>>> compiler info: gnuc: 10.1\n>>> libc info: no libc information available\n>>>\n>>>\n>>> [Enabled Hooks]\n>>>\n\n"},{"id":"401926","messageId":"CAK1xKQppM3oseB=vdXbDbPjDeFxd9kd0jULcaC=ASkMsKiDCmQ@mail.gmail.com","threadId":"53896","inReplyTo":"fc38a32f-91e2-fe49-a7b0-e2e6851271c4@gmail.com","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Joel Marshall","fromEmail":"joelmdev@gmail.com","sentAt":"2020-07-23T14:09:23Z","receivedAt":"2020-07-23T14:09:44Z","isPatch":false,"sender":{"key":"joelmdev@gmail.com","avatar":"https://gravatar.com/avatar/b4fdc9936cac61479f181b58d8a33552c36e06f4f2ea7f0361431daa6d50e1d4?d=mp&s=160"},"body":"I saved the state of the repo in a copy so I could come back to it if\nadditional examples were needed but I had to clean up my live copy so\nI could get back to work. I'll get you some additional screenshots in\nthe next few days. In the meantime, I'll try to give you some context\naround what I'm doing here. The parent branch is my main dev branch\nwhich consists of a series of clean branches and merges- the dev\nbranch basically looks like what you're seeing in the\n--preserve-merges screenshot. I've also got a long running feature\nbranch that branches off of dev, and it also consists of many branches\nand merges, each a subtask of the story related to the feature branch\nas a whole. Occasionally to get the feature branch up to date with the\nnewest features I'll rebase the whole thing on top of dev, which\nshould result in an unbroken chain of branches and merges as seen in\nthe --preserve-merges screenshot. While you can't see it in the\n--rebase-merges screenshot, those merges show no ancestors when viewed\nin reverse chronological order- they just trail off into oblivion.\n\nOn Wed, Jul 22, 2020 at 2:30 PM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>\n> Hi Joel\n>\n> On 22/07/2020 18:09, Joel Marshall wrote:\n> > I've attached a couple of screenshots from tortoisegit. The branches\n> > are too long to show in their entirety, but this should give you an\n> > idea of what I'm talking about. The highlighted commit is the head of\n> > the branch that I'm rebasing onto. Interestingly, I just noticed that\n> > while --rebase merges reports that it's rebasing 202 commits\n> > intitially, upon manually reconciling the first conflict it reports\n> > that it is rebasing 183 commits.\n>\n> Thanks, the rebased topologies are certainly quite different, what is\n> the topology before the rebase? Looking at the --rebase-merges result it\n> looks like the second parents of merges that are being rebased have\n> ancestors in the upstream branch. If that is the case then I think it is\n> working as intended.\n>\n>  Are you able to run\n>\n>   git log --format=%ad --graph $upstream..HEAD\n>\n> before and after the rebase to check that?\n>\n> Best Wishes\n>\n> Phillip\n>\n> > On Wed, Jul 22, 2020 at 10:22 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n> >>\n> >> Hi Joel\n> >>\n> >> On 21/07/2020 22:20, Joel Marshall wrote:\n> >>> Thank you for filling out a Git bug report!\n> >>> Please answer the following questions to help us understand your issue.\n> >>>\n> >>> What did you do before the bug happened? (Steps to reproduce your issue)\n> >>> This is a difficult one to give proper steps to reproduce. The issue\n> >>> is with rebase's --rebase-merges flag. We recently switched from using\n> >>> rebase with the --preserve-merges option to --rebase-merges. Most of\n> >>> the time the output is the same, but sometimes it is very different.\n> >>> I'm unable to determine whether this is by design or a bug.\n> >>\n> >> --preserve-merges is buggy if you rearrange the commits (this is way\n> >> --rebase-merges was added), if you're just rebasing without reordering\n> >> anything then I think the result should be the same though there may be\n> >> some corner cases I'm not aware of. Are you able to share the topology\n> >> before rebasing and after with --preserve-merges and --rebase-merges?\n> >>\n> >>> What did you expect to happen? (Expected behavior)\n> >>> Resulting graph after running rebase --rebase-merges is the same as\n> >>> running rebase --preserve-merges.\n> >>>\n> >>> What happened instead? (Actual behavior)\n> >>> Using --rebase merges tries to pick substantially more commits and\n> >>> results in merge commits with no parent commit when viewing log in\n> >>> reverse chronological order.\n> >>>\n> >>> What's different between what you expected and what actually happened?\n> >>> When the issue does occur (it doesn't for all rebases) it results in\n> >>> two completely different logs and picks commits that are apparently\n> >>> not part of the branch being rebased. eg, for a branch with 128\n> >>> commits including merges, --preserve-merges picks 128 commits and the\n> >>> resulting topology matches the original branch's topology.\n> >>> --rebase-merges picked 183(?) commits in v2.24 and 202 commits in\n> >>> v2.27, and in both cases resulted in a very strange topology.\n> >>\n> >> That's interesting there were some changes to how empty commits and\n> >> upstreamed commits are handled between v2.24 and v2.17, without seeing\n> >> the staring point and the results it's hard to tell what is going on though.\n> >>\n> >> Without seeing some examples it's hard to tell if there is a bug here or\n> >> not though it does sound a bit suspicious.\n> >>\n> >>> Anything else you want to add:\n> >>> Feel free to contact me at joel@tusksoft.com for additional details.\n> >>\n> >> You email me directly if there are things you don't want to share on the\n> >> list\n> >>\n> >> Best wishes\n> >>\n> >> Phillip\n> >>\n> >>> I\n> >>> would love to understand if this is by design or a legitimate bug.\n> >>>\n> >>> Please review the rest of the bug report below.\n> >>> You can delete any lines you don't wish to share.\n> >>>\n> >>>\n> >>> [System Info]\n> >>> git version:\n> >>> git version 2.27.0.windows.1\n> >>> cpu: x86_64\n> >>> built from commit: 907ab1011dce9112700498e034b974ba60f8b407\n> >>> sizeof-long: 4\n> >>> sizeof-size_t: 8\n> >>> uname: Windows 10.0 18363\n> >>> compiler info: gnuc: 10.1\n> >>> libc info: no libc information available\n> >>>\n> >>>\n> >>> [Enabled Hooks]\n> >>>\n>\n"},{"id":"403265","messageId":"nycvar.QRO.7.76.6.2008101645410.50@tvgsbejvaqbjf.bet","threadId":"53896","inReplyTo":"CAK1xKQppM3oseB=vdXbDbPjDeFxd9kd0jULcaC=ASkMsKiDCmQ@mail.gmail.com","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-08-10T14:46:48Z","receivedAt":"2020-08-10T14:46:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Joel,\n\nOn Thu, 23 Jul 2020, Joel Marshall wrote:\n\n> I saved the state of the repo in a copy so I could come back to it if\n> additional examples were needed but I had to clean up my live copy so\n> I could get back to work. I'll get you some additional screenshots in\n> the next few days. In the meantime, I'll try to give you some context\n> around what I'm doing here. The parent branch is my main dev branch\n> which consists of a series of clean branches and merges- the dev\n> branch basically looks like what you're seeing in the\n> --preserve-merges screenshot. I've also got a long running feature\n> branch that branches off of dev, and it also consists of many branches\n> and merges, each a subtask of the story related to the feature branch\n> as a whole. Occasionally to get the feature branch up to date with the\n> newest features I'll rebase the whole thing on top of dev, which\n> should result in an unbroken chain of branches and merges as seen in\n> the --preserve-merges screenshot. While you can't see it in the\n> --rebase-merges screenshot, those merges show no ancestors when viewed\n> in reverse chronological order- they just trail off into oblivion.\n\nI could imagine that you might want to try this rebase with\n`--rebase-merges=rebase-cousins`.\n\nOtherwise, you might want to export your use case with `git fast-export\n--anonymize` so that others (such as myself) have a chance of helping you.\n\nCiao,\nJohannes\n"},{"id":"443517","messageId":"CAK1xKQpTUqLLZkYuFEOx7zy8wOib_ohwmiqt89qoj-rK8tnZ4A@mail.gmail.com","threadId":"53896","inReplyTo":"nycvar.QRO.7.76.6.2008101645410.50@tvgsbejvaqbjf.bet","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Joel Marshall","fromEmail":"joelmdev@gmail.com","sentAt":"2021-12-08T20:46:12Z","receivedAt":"2021-12-08T20:46:34Z","isPatch":false,"sender":{"key":"joelmdev@gmail.com","avatar":"https://gravatar.com/avatar/b4fdc9936cac61479f181b58d8a33552c36e06f4f2ea7f0361431daa6d50e1d4?d=mp&s=160"},"body":"Hi all,\n\nSorry to drop off on this for so long. I think this is still a\npossible outstanding issue, yes? If so I will work on getting you a\ncopy of the repo as I did archive a copy at the state originally\nmentioned in this issue.\n\nOn Mon, Aug 10, 2020 at 10:46 AM Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> Hi Joel,\n>\n> On Thu, 23 Jul 2020, Joel Marshall wrote:\n>\n> > I saved the state of the repo in a copy so I could come back to it if\n> > additional examples were needed but I had to clean up my live copy so\n> > I could get back to work. I'll get you some additional screenshots in\n> > the next few days. In the meantime, I'll try to give you some context\n> > around what I'm doing here. The parent branch is my main dev branch\n> > which consists of a series of clean branches and merges- the dev\n> > branch basically looks like what you're seeing in the\n> > --preserve-merges screenshot. I've also got a long running feature\n> > branch that branches off of dev, and it also consists of many branches\n> > and merges, each a subtask of the story related to the feature branch\n> > as a whole. Occasionally to get the feature branch up to date with the\n> > newest features I'll rebase the whole thing on top of dev, which\n> > should result in an unbroken chain of branches and merges as seen in\n> > the --preserve-merges screenshot. While you can't see it in the\n> > --rebase-merges screenshot, those merges show no ancestors when viewed\n> > in reverse chronological order- they just trail off into oblivion.\n>\n> I could imagine that you might want to try this rebase with\n> `--rebase-merges=rebase-cousins`.\n>\n> Otherwise, you might want to export your use case with `git fast-export\n> --anonymize` so that others (such as myself) have a chance of helping you.\n>\n> Ciao,\n> Johannes\n"},{"id":"451925","messageId":"CAK1xKQqGTmgGBH4TY2mpHZLit_49FDoEq2EewDE-v_fc2=ikYA@mail.gmail.com","threadId":"53896","inReplyTo":"CAK1xKQpTUqLLZkYuFEOx7zy8wOib_ohwmiqt89qoj-rK8tnZ4A@mail.gmail.com","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Joel Marshall","fromEmail":"joelmdev@gmail.com","sentAt":"2022-03-22T20:13:10Z","receivedAt":"2022-03-22T20:13:36Z","isPatch":false,"sender":{"key":"joelmdev@gmail.com","avatar":"https://gravatar.com/avatar/b4fdc9936cac61479f181b58d8a33552c36e06f4f2ea7f0361431daa6d50e1d4?d=mp&s=160"},"body":"I have confirmed that this is still an issue under certain\ncircumstances. --rebase-merges works as expected if it is being used\nwith simple feature branches, ie one commit after the other, no\nmerges. Where things go off of the rails is when there are branches\nand merges coming off of and going into a feature branch. At that\npoint using the --rebase-merges flag with rebase will create a similar\nmess to the images of the logs I attached back in July of 2022.\n\nOn Wed, Dec 8, 2021 at 3:46 PM Joel Marshall <joelmdev@gmail.com> wrote:\n>\n> Hi all,\n>\n> Sorry to drop off on this for so long. I think this is still a\n> possible outstanding issue, yes? If so I will work on getting you a\n> copy of the repo as I did archive a copy at the state originally\n> mentioned in this issue.\n>\n> On Mon, Aug 10, 2020 at 10:46 AM Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > Hi Joel,\n> >\n> > On Thu, 23 Jul 2020, Joel Marshall wrote:\n> >\n> > > I saved the state of the repo in a copy so I could come back to it if\n> > > additional examples were needed but I had to clean up my live copy so\n> > > I could get back to work. I'll get you some additional screenshots in\n> > > the next few days. In the meantime, I'll try to give you some context\n> > > around what I'm doing here. The parent branch is my main dev branch\n> > > which consists of a series of clean branches and merges- the dev\n> > > branch basically looks like what you're seeing in the\n> > > --preserve-merges screenshot. I've also got a long running feature\n> > > branch that branches off of dev, and it also consists of many branches\n> > > and merges, each a subtask of the story related to the feature branch\n> > > as a whole. Occasionally to get the feature branch up to date with the\n> > > newest features I'll rebase the whole thing on top of dev, which\n> > > should result in an unbroken chain of branches and merges as seen in\n> > > the --preserve-merges screenshot. While you can't see it in the\n> > > --rebase-merges screenshot, those merges show no ancestors when viewed\n> > > in reverse chronological order- they just trail off into oblivion.\n> >\n> > I could imagine that you might want to try this rebase with\n> > `--rebase-merges=rebase-cousins`.\n> >\n> > Otherwise, you might want to export your use case with `git fast-export\n> > --anonymize` so that others (such as myself) have a chance of helping you.\n> >\n> > Ciao,\n> > Johannes\n"},{"id":"452115","messageId":"nycvar.QRO.7.76.6.2203241440130.388@tvgsbejvaqbjf.bet","threadId":"53896","inReplyTo":"CAK1xKQqGTmgGBH4TY2mpHZLit_49FDoEq2EewDE-v_fc2=ikYA@mail.gmail.com","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-24T13:42:31Z","receivedAt":"2022-03-24T13:42:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Joel,\n\nplease reply inline. What you did is called \"top-posting\" on this list and\nis regularly discouraged.\n\nOn Tue, 22 Mar 2022, Joel Marshall wrote:\n\n> I have confirmed that this is still an issue under certain\n> circumstances. --rebase-merges works as expected if it is being used\n> with simple feature branches, ie one commit after the other, no\n> merges. Where things go off of the rails is when there are branches\n> and merges coming off of and going into a feature branch. At that\n> point using the --rebase-merges flag with rebase will create a similar\n> mess to the images of the logs I attached back in July of 2022.\n\nI wonder what happened to my suggestions to use\n`--rebase-merges=rebase-cousins` or `git fast-export --anonymize`. They\nseem to have faded without any echo.\n\nCiao,\nJohannes\n\n>\n> On Wed, Dec 8, 2021 at 3:46 PM Joel Marshall <joelmdev@gmail.com> wrote:\n> >\n> > Hi all,\n> >\n> > Sorry to drop off on this for so long. I think this is still a\n> > possible outstanding issue, yes? If so I will work on getting you a\n> > copy of the repo as I did archive a copy at the state originally\n> > mentioned in this issue.\n> >\n> > On Mon, Aug 10, 2020 at 10:46 AM Johannes Schindelin\n> > <Johannes.Schindelin@gmx.de> wrote:\n> > >\n> > > Hi Joel,\n> > >\n> > > On Thu, 23 Jul 2020, Joel Marshall wrote:\n> > >\n> > > > I saved the state of the repo in a copy so I could come back to it if\n> > > > additional examples were needed but I had to clean up my live copy so\n> > > > I could get back to work. I'll get you some additional screenshots in\n> > > > the next few days. In the meantime, I'll try to give you some context\n> > > > around what I'm doing here. The parent branch is my main dev branch\n> > > > which consists of a series of clean branches and merges- the dev\n> > > > branch basically looks like what you're seeing in the\n> > > > --preserve-merges screenshot. I've also got a long running feature\n> > > > branch that branches off of dev, and it also consists of many branches\n> > > > and merges, each a subtask of the story related to the feature branch\n> > > > as a whole. Occasionally to get the feature branch up to date with the\n> > > > newest features I'll rebase the whole thing on top of dev, which\n> > > > should result in an unbroken chain of branches and merges as seen in\n> > > > the --preserve-merges screenshot. While you can't see it in the\n> > > > --rebase-merges screenshot, those merges show no ancestors when viewed\n> > > > in reverse chronological order- they just trail off into oblivion.\n> > >\n> > > I could imagine that you might want to try this rebase with\n> > > `--rebase-merges=rebase-cousins`.\n> > >\n> > > Otherwise, you might want to export your use case with `git fast-export\n> > > --anonymize` so that others (such as myself) have a chance of helping you.\n> > >\n> > > Ciao,\n> > > Johannes\n>\n"},{"id":"452463","messageId":"1cb32296-6b46-0a0e-76c6-3d9fbbf7b21d@iee.email","threadId":"53896","inReplyTo":"nycvar.QRO.7.76.6.2203241440130.388@tvgsbejvaqbjf.bet","subject":"Re: Possible issue with rebase's --rebase-merges option","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-03-28T11:21:45Z","receivedAt":"2022-03-28T11:24:24Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Joel,\n\nOn 24/03/2022 13:42, Johannes Schindelin wrote:\n> Hi Joel,\n>\n> please reply inline. What you did is called \"top-posting\" on this list and\n> is regularly discouraged.\n>\n> On Tue, 22 Mar 2022, Joel Marshall wrote:\n>\n>> I have confirmed that this is still an issue under certain\n>> circumstances. --rebase-merges works as expected if it is being used\n>> with simple feature branches, ie one commit after the other, no\n>> merges. Where things go off of the rails is when there are branches\n>> and merges coming off of and going into a feature branch. At that\n>> point using the --rebase-merges flag with rebase will create a similar\n>> mess to the images of the logs I attached back in July of 2022.\n> I wonder what happened to my suggestions to use\n> `--rebase-merges=rebase-cousins` or `git fast-export --anonymize`. They\n> seem to have faded without any echo.\n>\n> Ciao,\n> Johannes\n>\n\nThe rebasing of merges can be confusing, with the different perspectives \n(mental models) about which line of development the merges arrive from.\n\nIn support of Johannes' note, the stack overflow Q&A [1] does contain \nsome nice diagrams showing the different ways that a history can be \ninterpreted, and the effect that \"cousins\" have on the picture \n(understanding not helped by many colloquial familial uses of 'cousins' \nthat are not technically correct ;-).\n\nYour case of two parallel lines of development, with merges from one to \nthe other, being rebased from the original fork-point, does look to fit \nthat 'difference of mental model' confusion.\n\nDoes that SO Q&A help clarify the situation. If you are able to create a \nsimilar simplified hierarchy (e.g. cut out the long linear sections) of \nyour scenario then it becomes easier to help.\n\nPhilip\n[1] \nhttps://stackoverflow.com/questions/56529435/what-is-the-behavior-of-the-cousins-options-in-git-rebase-rebase-merges\n>> On Wed, Dec 8, 2021 at 3:46 PM Joel Marshall <joelmdev@gmail.com> wrote:\n>>> Hi all,\n>>>\n>>> Sorry to drop off on this for so long. I think this is still a\n>>> possible outstanding issue, yes? If so I will work on getting you a\n>>> copy of the repo as I did archive a copy at the state originally\n>>> mentioned in this issue.\n>>>\n>>> On Mon, Aug 10, 2020 at 10:46 AM Johannes Schindelin\n>>> <Johannes.Schindelin@gmx.de> wrote:\n>>>> Hi Joel,\n>>>>\n>>>> On Thu, 23 Jul 2020, Joel Marshall wrote:\n>>>>\n>>>>> I saved the state of the repo in a copy so I could come back to it if\n>>>>> additional examples were needed but I had to clean up my live copy so\n>>>>> I could get back to work. I'll get you some additional screenshots in\n>>>>> the next few days. In the meantime, I'll try to give you some context\n>>>>> around what I'm doing here. The parent branch is my main dev branch\n>>>>> which consists of a series of clean branches and merges- the dev\n>>>>> branch basically looks like what you're seeing in the\n>>>>> --preserve-merges screenshot. I've also got a long running feature\n>>>>> branch that branches off of dev, and it also consists of many branches\n>>>>> and merges, each a subtask of the story related to the feature branch\n>>>>> as a whole. Occasionally to get the feature branch up to date with the\n>>>>> newest features I'll rebase the whole thing on top of dev, which\n>>>>> should result in an unbroken chain of branches and merges as seen in\n>>>>> the --preserve-merges screenshot. While you can't see it in the\n>>>>> --rebase-merges screenshot, those merges show no ancestors when viewed\n>>>>> in reverse chronological order- they just trail off into oblivion.\n>>>> I could imagine that you might want to try this rebase with\n>>>> `--rebase-merges=rebase-cousins`.\n>>>>\n>>>> Otherwise, you might want to export your use case with `git fast-export\n>>>> --anonymize` so that others (such as myself) have a chance of helping you.\n>>>>\n>>>> Ciao,\n>>>> Johannes\n\n"}]}