{"thread":{"id":"56532","subject":"Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","startedAt":"2021-09-18T14:18:55Z","lastAt":"2021-10-06T14:03:44Z","messageCount":9,"participants":["Philip Oakley","Jeff King","Ævar Arnfjörð Bjarmason","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"436308","messageId":"01fe28d8-2887-bc42-c91b-c3237b5186a7@iee.email","threadId":"56532","inReplyTo":null,"subject":"Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-09-18T14:18:47Z","receivedAt":"2021-09-18T14:18:55Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi all,\n\nIs there a method within `git rev-list` to trim side branch merges where\nthe merge's tree is identical to the first parent's commit-tree?\n\nOne back-story: In the Git-for Windows repository, the previous releases\nare 'deadheaded' by merging with the upstream git, and simply taking the\nupstream's tree unconditionally. The Git-for-Windows `fixes` are then\nrebased onto that merge.\n\nThis does mean that all the fixes keep repeating down the 2nd parent\nline. So, for example, grep'ing for changes can tricky with so much\nrepeated chaff, but at least all old versions are directly in the history.\n\nSometimes it's nice to 'pretend' (a simplified history) that there is\nonly the one latest series of this 'long lived feature branch' (along\nwith a similar desire for 'gfw/next` and `gfw/seen`). (one method has\nbeen to `git replace` that merge commit `{/\"Start the\"}` with it's\nparent on a temporary basis).\n\nFrom my reading of the `rev-list` manual this is similar to the <paths>\nTREESAME capability, but without specifying any paths (maybe just `.` ?).\n\n* Is there an existing method for specifying that simplified history?\n* Is there a proper term for the treesame condition of the commit-tree\n(as recorded in the commit object)?\n* Thought's on adding an option for `--follow-treesame`?\n\nThe desire also came up in my pondering about progressive/partial merges\n(how to represent/hold current state/history) of a large tree, whereby\ndifferent authors take different 'bites at the melon' of merging a long\nlasting feature branch (the 'ball of mud' type), whereby the result\ncould be an octopus merge of the main/feature/partial commits, which is\nrepeated until the partial becomes a finalised merge (the book-ending\nand octo-merge is still wip, but would also benefit from the 'feature'\nmerge technique used by GfW.\n\n--\nPhilip\n"},{"id":"436377","messageId":"YUeImAqA0SZAdA2R@coredump.intra.peff.net","threadId":"56532","inReplyTo":"01fe28d8-2887-bc42-c91b-c3237b5186a7@iee.email","subject":"Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-09-19T18:59:36Z","receivedAt":"2021-09-19T19:04:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 18, 2021 at 03:18:47PM +0100, Philip Oakley wrote:\n\n> Is there a method within `git rev-list` to trim side branch merges where\n> the merge's tree is identical to the first parent's commit-tree?\n> [...]\n> From my reading of the `rev-list` manual this is similar to the <paths>\n> TREESAME capability, but without specifying any paths (maybe just `.` ?).\n\nYes, I'd just do \"git log .\" for this. I don't think there's another way\nto trigger simplification. In try_to_simplify_commit(), we bail early\nunless revs->prune is set, and that is set only by the presence of\npathspecs or by --simplify-by-decoration.\n\n> * Is there a proper term for the treesame condition of the commit-tree\n> (as recorded in the commit object)?\n\nIn a one-parent commit, I'd just call it an empty commit. For a merge,\nit is really I'd probably call it an \"ours\" merge, since one obvious way\nto get there is with \"git merge -s ours\" (of course you can also just\nresolve all conflicts in favor of one parent). I don't know of another\nname (besides treesame, of course, but that generally implies a\nparticular scope of interest given by a pathspec).\n\n-Peff\n"},{"id":"436388","messageId":"87k0jcb01k.fsf@evledraar.gmail.com","threadId":"56532","inReplyTo":"YUeImAqA0SZAdA2R@coredump.intra.peff.net","subject":"Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-09-19T23:44:23Z","receivedAt":"2021-09-19T23:47:24Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Sep 19 2021, Jeff King wrote:\n\n> On Sat, Sep 18, 2021 at 03:18:47PM +0100, Philip Oakley wrote:\n>\n>> Is there a method within `git rev-list` to trim side branch merges where\n>> the merge's tree is identical to the first parent's commit-tree?\n>> [...]\n>> From my reading of the `rev-list` manual this is similar to the <paths>\n>> TREESAME capability, but without specifying any paths (maybe just `.` ?).\n>\n> Yes, I'd just do \"git log .\" for this. I don't think there's another way\n> to trigger simplification. In try_to_simplify_commit(), we bail early\n> unless revs->prune is set, and that is set only by the presence of\n> pathspecs or by --simplify-by-decoration.\n>\n>> * Is there a proper term for the treesame condition of the commit-tree\n>> (as recorded in the commit object)?\n>\n> In a one-parent commit, I'd just call it an empty commit. For a merge,\n> it is really I'd probably call it an \"ours\" merge, since one obvious way\n> to get there is with \"git merge -s ours\" (of course you can also just\n> resolve all conflicts in favor of one parent). I don't know of another\n> name (besides treesame, of course, but that generally implies a\n> particular scope of interest given by a pathspec).\n\nIsn't it a \"theirs\" merge, not \"ours\"? Per the description Philip has:\n\n    In the Git-for Windows repository, the previous releases are\n    'deadheaded' by merging with the upstream git, and simply taking the\n    upstream's tree unconditionally[...]\n\nI.e. if you're taking your tree unconditionally it's -s ours, but -s\ntheirs for theirs. Except of course for the small matter of us not\nhaving a \"-s theirs\" yet.\n\nI had a WIP patch a while ago for a \"-s theirs -X N\", for what sounds\nlike a similar use-case:\nhttps://lore.kernel.org/git/87sh7sdtc1.fsf@evledraar.gmail.com/\n"},{"id":"436408","messageId":"88dfc31a-187c-6609-0df6-d6b970b1a136@iee.email","threadId":"56532","inReplyTo":"87k0jcb01k.fsf@evledraar.gmail.com","subject":"Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-09-20T11:40:21Z","receivedAt":"2021-09-20T11:40:25Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 20/09/2021 00:44, Ævar Arnfjörð Bjarmason wrote:\n> On Sun, Sep 19 2021, Jeff King wrote:\n>\n>> On Sat, Sep 18, 2021 at 03:18:47PM +0100, Philip Oakley wrote:\n>>\n>>> Is there a method within `git rev-list` to trim side branch merges where\n>>> the merge's tree is identical to the first parent's commit-tree?\n>>> [...]\n>>> From my reading of the `rev-list` manual this is similar to the <paths>\n>>> TREESAME capability, but without specifying any paths (maybe just `.` ?).\n>> Yes, I'd just do \"git log .\" for this. I don't think there's another way\n>> to trigger simplification. In try_to_simplify_commit(), we bail early\n>> unless revs->prune is set, and that is set only by the presence of\n>> pathspecs or by --simplify-by-decoration.\n>>\n>>> * Is there a proper term for the treesame condition of the commit-tree\n>>> (as recorded in the commit object)?\n>> In a one-parent commit, I'd just call it an empty commit. For a merge,\n>> it is really I'd probably call it an \"ours\" merge, since one obvious way\n>> to get there is with \"git merge -s ours\" (of course you can also just\n>> resolve all conflicts in favor of one parent). I don't know of another\n>> name (besides treesame, of course, but that generally implies a\n>> particular scope of interest given by a pathspec).\n> Isn't it a \"theirs\" merge, not \"ours\"? Per the description Philip has:\n>\n>     In the Git-for Windows repository, the previous releases are\n>     'deadheaded' by merging with the upstream git, and simply taking the\n>     upstream's tree unconditionally[...]\n\nIn that sense, yes. From the gfw branch's perspective, the merge is 100%\nthat of git/master. It provides an 'out-of-line' commit onto which the\ngfw patches can be rebased.\nIt's almost identical to a ball-of-mud progressive (incremental) merge,\nbut neatly refactored.\n>\n> I.e. if you're taking your tree unconditionally it's -s ours, but -s\n> theirs for theirs. Except of course for the small matter of us not\n> having a \"-s theirs\" yet.\n\nThere used to be a `theirs` strategy but (IIRC) it was removed by Linus\nyears ago (before I discovered git and it's ability to distribute\ncontrol..).\n\nOne thing that catches me, and I think others, is how the 'strategies'\nwork. IIUC a merge will look at each line in the diff, and accept any\nchange on either side that has no conflicts within the context zone.\nIt's only when there are changes from both sides that the selection\nstrategy kicks in. But it is difficult to describe, so it's easy to be\nconfused.\n\nIt doesn't look like this type of rebasing workflow for a\nmulti-platform/product scenarios was considered at the time. [1-4]\n\nEither way, having a few clues (where to look in the code) to including\na `--deadhead` history simplification is useful.\n>\n> I had a WIP patch a while ago for a \"-s theirs -X N\", for what sounds\n> like a similar use-case:\n> https://lore.kernel.org/git/87sh7sdtc1.fsf@evledraar.gmail.com/\n\n[1]\nhttps://stackoverflow.com/questions/173919/is-there-a-theirs-version-of-git-merge-s-ours\n[2]\nhttps://lore.kernel.org/git/alpine.DEB.1.00.0807290123300.2725@eeepc-johanness/\n[3] https://lore.kernel.org/git/7vtzen7bul.fsf@gitster.siamese.dyndns.org/\n[4]\nhttps://lore.kernel.org/git/xmqqmv5je412.fsf_-_@gitster.mtv.corp.google.com/\n"},{"id":"436456","messageId":"YUj0J+jY0jURkipM@coredump.intra.peff.net","threadId":"56532","inReplyTo":"88dfc31a-187c-6609-0df6-d6b970b1a136@iee.email","subject":"Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-09-20T20:50:47Z","receivedAt":"2021-09-20T20:52:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 20, 2021 at 12:40:21PM +0100, Philip Oakley wrote:\n\n> One thing that catches me, and I think others, is how the 'strategies'\n> work. IIUC a merge will look at each line in the diff, and accept any\n> change on either side that has no conflicts within the context zone.\n> It's only when there are changes from both sides that the selection\n> strategy kicks in. But it is difficult to describe, so it's easy to be\n> confused.\n\nI think you might be confusing the \"ours\" strategy (which takes the\ntree state of the first parent entirely) with the \"ours\" (and \"theirs\")\noptions of the merge-recursive (or ort) strategy.\n\nYou can see the difference with:\n\n  git init repo\n  cd repo\n  \n  echo base >file\n  git add file\n  git commit -m base\n  \n  echo main >file\n  git add file\n  git commit -m main\n  \n  git checkout -b side HEAD^\n  echo side >file\n  echo unrelated >another\n  git add file another\n  git commit -m side\n  \n  git checkout -b strategy-ours main\n  git merge -s ours side\n  \n  git checkout -b option-ours main\n  git merge -X ours side\n\nThe strategy-ours merge will drop \"another\", because it was not in the\nfirst parent. Whereas option-ours will keep it, preferring the\nfirst parent only for the conflict in \"file\".\n\nYou could construct a similar example where instead of a second file,\nthere's enough content in \"file\" that some of it does not conflict.\n\n-Peff\n"},{"id":"436613","messageId":"9b85811f-de5d-24b3-36f6-7e2f9be6cae0@iee.email","threadId":"56532","inReplyTo":"YUj0J+jY0jURkipM@coredump.intra.peff.net","subject":"Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-09-21T13:36:04Z","receivedAt":"2021-09-21T13:36:07Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Peff,\nOn 20/09/2021 21:50, Jeff King wrote:\n> On Mon, Sep 20, 2021 at 12:40:21PM +0100, Philip Oakley wrote:\n>\n>> One thing that catches me, and I think others, is how the 'strategies'\n>> work. IIUC a merge will look at each line in the diff, and accept any\n>> change on either side that has no conflicts within the context zone.\n>> It's only when there are changes from both sides that the selection\n>> strategy kicks in. But it is difficult to describe, so it's easy to be\n>> confused.\n> I think you might be confusing the \"ours\" strategy (which takes the\n> tree state of the first parent entirely) with the \"ours\" (and \"theirs\")\n> options of the merge-recursive (or ort) strategy.\n>\n> You can see the difference with:\n>\n>   git init repo\n>   cd repo\n>   \n>   echo base >file\n>   git add file\n>   git commit -m base\n>   \n>   echo main >file\n>   git add file\n>   git commit -m main\n>   \n>   git checkout -b side HEAD^\n>   echo side >file\n>   echo unrelated >another\n>   git add file another\n>   git commit -m side\n>   \n>   git checkout -b strategy-ours main\n>   git merge -s ours side\n>   \n>   git checkout -b option-ours main\n>   git merge -X ours side\n>\n> The strategy-ours merge will drop \"another\", because it was not in the\n> first parent. Whereas option-ours will keep it, preferring the\n> first parent only for the conflict in \"file\".\n>\n> You could construct a similar example where instead of a second file,\n> there's enough content in \"file\" that some of it does not conflict.\n>\n> -Peff\nThanks for the clarification.\nI was probably over thinking the problem, by starting at the default and\nadding conditions that are extras to that, rather than  reducing the\nconditions!\n\nThe `theirs` strategy is really only suitable for maintainers, rather\nthan solo coders, as it need to be 'old releases` that are kept, rather\n'old cruft` (I've generated too much of that in my time).\n\nDscho's scripts (for anyone interested) for GfW are in\nhttps://github.com/git-for-windows/build-extra/blob/main/shears.sh#L16-L18\nand \nhttps://github.com/git-for-windows/build-extra/blob/main/ever-green.sh,\nthough from the script perspective it's an 'ours' strategy.\n\nDscho has to locate the start commit via it's subject line, rather than\nit's topology.\n\n--\nPhilip\n"},{"id":"436651","messageId":"be7ec330-2b2c-a01f-c7ca-e5e752493ee0@iee.email","threadId":"56532","inReplyTo":"9b85811f-de5d-24b3-36f6-7e2f9be6cae0@iee.email","subject":"Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-09-21T18:24:59Z","receivedAt":"2021-09-21T18:25:02Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 21/09/2021 14:36, Philip Oakley wrote:\n> The `theirs` strategy is really only suitable for maintainers, rather\n> than solo coders, as it need to be 'old releases` that are kept, rather\n> 'old cruft` (I've generated too much of that in my time).\n>\n> Dscho's scripts (for anyone interested) for GfW are in\n> https://github.com/git-for-windows/build-extra/blob/main/shears.sh#L16-L18\n> and \n> https://github.com/git-for-windows/build-extra/blob/main/ever-green.sh,\n> though from the script perspective it's an 'ours' strategy.\n>\n> Dscho has to locate the start commit via it's subject line, rather than\n> it's topology.\n\nIt's taken me a while to realise why/how Dscho is using 'ours', for a\n'theirs' merge.\n\nHe is inserting that merge into the start of the --merging-rebase's\ninstruction sheet, which means that the rebase itself will reverse the\nmeaning of 'ours' and 'theirs' as it checks out the 'theirs' branch\nfirst before performing the actions in the instruction sheet.\n\nThus the 'ours' strategy now works in our favour, to effectively\ndeadhead the old hear as a 'theirs' merge and then begin the rebasing of\nthe Git-for-Windows patch thicket on top of the latest Git.\n\nSneaky.\n\n--\nPhilip\n(added dscho as cc, just in case I've got it wrong again;-)\n"},{"id":"437966","messageId":"nycvar.QRO.7.76.6.2110051244000.395@tvgsbejvaqbjf.bet","threadId":"56532","inReplyTo":"01fe28d8-2887-bc42-c91b-c3237b5186a7@iee.email","subject":"Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-10-05T10:53:42Z","receivedAt":"2021-10-05T10:53:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Philip,\n\nOn Sat, 18 Sep 2021, Philip Oakley wrote:\n\n> Is there a method within `git rev-list` to trim side branch merges where\n> the merge's tree is identical to the first parent's commit-tree?\n\nYes, there is, but it is not as easy as a command-line option: `git\nreplace`.\n\nFor example, to pretend that the most recent merging-rebase in Git for\nWindows was (almost) a regular rebase, you replace the \"Start the\nmerging-rebase\" commit with a graft that only keeps its first parent:\n\n\tgit replace --graft HEAD^{/^Start.the} HEAD^{/^Start.the}^\n\n(Of course, you still have to find out the first-parent-treesame merge\ncommits that you want to replace.)\n\nIf you want to do that only temporarily, you can use a throw-away\nnamespace instead of the refs/replace/ one:\n\n\texport GIT_REPLACE_REF_BASE=refs/philipoakley/\n\tgit replace --graft HEAD^{/^Start.the} HEAD^{/^Start.the}^\n\nBefore:\n\n\t[...]\n\t| > | | 23e09ef1080 Merge 'remote-hg-prerequisites' into HEAD\n\t|/| | |\n\t| > | | 0221569db1c Always auto-gc after calling a fast-import transport\n\t| > | | f189282dcfc remote-helper: check helper status after import/export\n\t| > | | 158907ceb87 transport-helper: add trailing --\n\t| > | | 6e34e54050c t9350: point out that refs are not updated correctly\n\t|/ / /\n\t> | |   7b2b910b080 Start the merging-rebase to v2.33.0\n\t|\\ \\ \\\n\t| |_|/\n\t|/| |\n\t| > |   508bb26ff90 (tag: v2.33.0-rc2.windows.1) Merge pull request #3349 from vdye/feature/ci-subtree-tests\n\t[...]\n\nAfter:\n\n\t[...]\n\t| > | | 23e09ef1080 Merge 'remote-hg-prerequisites' into HEAD\n\t|/| | |\n\t| > | | 0221569db1c Always auto-gc after calling a fast-import transport\n\t| > | | f189282dcfc remote-helper: check helper status after import/export\n\t| > | | 158907ceb87 transport-helper: add trailing --\n\t| > | | 6e34e54050c t9350: point out that refs are not updated correctly\n\t|/ / /\n\t> | / 7b2b910b080 (replaced) Start the merging-rebase to v2.33.0\n\t| |/\n\t|/|\n\t> | 225bc32a989 (tag: v2.33.0, upstream/maint, mirucam/maint, gitgitgadget/snap, gitgitgadget/maint) Git 2.33\n\t[...]\n\nYou can always clean up _all_ replace objects via `git replace -d $(git\nreplace -l)`.\n\nCiao,\nDscho\n"},{"id":"438067","messageId":"7ac923e5-9bda-b534-a2f6-0be68fc80ed9@iee.email","threadId":"56532","inReplyTo":"nycvar.QRO.7.76.6.2110051244000.395@tvgsbejvaqbjf.bet","subject":"Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-10-06T14:03:41Z","receivedAt":"2021-10-06T14:03:44Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Dscho,\nOn 05/10/2021 11:53, Johannes Schindelin wrote:\n> Hi Philip,\n>\n> On Sat, 18 Sep 2021, Philip Oakley wrote:\n>\n>> Is there a method within `git rev-list` to trim side branch merges where\n>> the merge's tree is identical to the first parent's commit-tree?\n> Yes, there is, but it is not as easy as a command-line option: `git\n> replace`.\n>\n> For example, to pretend that the most recent merging-rebase in Git for\n> Windows was (almost) a regular rebase, you replace the \"Start the\n> merging-rebase\" commit with a graft that only keeps its first parent:\n>\n> \tgit replace --graft HEAD^{/^Start.the} HEAD^{/^Start.the}^\n\nIf I remember rightly, the ever-green script needs to go to special\nlengths to ensure that it gets the topographic (DAG) sort order, rather\nthan the default chrono - time ordered commit searching, which was part\nof the deadheads question.\n\nI need to learn the dot trick to avoid the quoting needed for the spaces\nin the commit message title! It always slips my mind. I've added a\npseudo alias for the command style (I can never remember what I named\nit.. but its easy to look up all aliases..) I also never remember that\n\"Start.the\" subject line..\n>\n> (Of course, you still have to find out the first-parent-treesame merge\n> commits that you want to replace.)\n\nI was thinking of cases beyond the current Git-for-Windows, that other\nmaintainers may start to use where keeping the 'deadheads' is a valid,\nor even required, part of their real-world projects, hence the idea of a\n`--deadheads` variant of 'first-parent'.\n>\n> If you want to do that only temporarily, you can use a throw-away\n> namespace instead of the refs/replace/ one:\n>\n> \texport GIT_REPLACE_REF_BASE=refs/philipoakley/\n> \tgit replace --graft HEAD^{/^Start.the} HEAD^{/^Start.the}^\n\nUseful.\n>\n> Before:\n>\n> \t[...]\n> \t| > | | 23e09ef1080 Merge 'remote-hg-prerequisites' into HEAD\n> \t|/| | |\n> \t| > | | 0221569db1c Always auto-gc after calling a fast-import transport\n> \t| > | | f189282dcfc remote-helper: check helper status after import/export\n> \t| > | | 158907ceb87 transport-helper: add trailing --\n> \t| > | | 6e34e54050c t9350: point out that refs are not updated correctly\n> \t|/ / /\n> \t> | |   7b2b910b080 Start the merging-rebase to v2.33.0\n> \t|\\ \\ \\\n> \t| |_|/\n> \t|/| |\n> \t| > |   508bb26ff90 (tag: v2.33.0-rc2.windows.1) Merge pull request #3349 from vdye/feature/ci-subtree-tests\n> \t[...]\n>\n> After:\n>\n> \t[...]\n> \t| > | | 23e09ef1080 Merge 'remote-hg-prerequisites' into HEAD\n> \t|/| | |\n> \t| > | | 0221569db1c Always auto-gc after calling a fast-import transport\n> \t| > | | f189282dcfc remote-helper: check helper status after import/export\n> \t| > | | 158907ceb87 transport-helper: add trailing --\n> \t| > | | 6e34e54050c t9350: point out that refs are not updated correctly\n> \t|/ / /\n> \t> | / 7b2b910b080 (replaced) Start the merging-rebase to v2.33.0\n> \t| |/\n> \t|/|\n> \t> | 225bc32a989 (tag: v2.33.0, upstream/maint, mirucam/maint, gitgitgadget/snap, gitgitgadget/maint) Git 2.33\n> \t[...]\n>\n> You can always clean up _all_ replace objects via `git replace -d $(git\n> replace -l)`.\n\nThat's a useful clean up tip. Thanks!\n\n>\n> Ciao,\n> Dscho\nThanks\nPhilip\n"}]}