{"thread":{"id":"66115","subject":"git-replay/git-history lose notes","startedAt":"2026-08-04T20:06:49Z","lastAt":"2026-08-07T15:16:13Z","messageCount":9,"participants":["D. Ben Knoble","Patrick Steinhardt","Phillip Wood","Junio C Hamano","Elijah Newren","erik88"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"549610","messageId":"CALnO6CAN1=dgRsYjABfa3CJkGnvb139EcrzS9EnX43i3szOgtQ@mail.gmail.com","threadId":"66115","inReplyTo":null,"subject":"git-replay/git-history lose notes","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-04T20:06:38Z","receivedAt":"2026-08-04T20:06:49Z","isPatch":false,"body":"Hi all,\n\nI don't think this has been reported or discussed yet, though my\napologies if my search skills just didn't find it.\n\nIt looks like git-replay and git-history will drop notes (or rather,\nnot carry them over) when rewriting history. I've seen this both with\n\"git replay --onto=… …\" and \"git history fixup\" recently, though I\nsuspect it affects all the modes.\n\nFortunately when I check range-diffs before pushing out new versions,\nI notice notes have disappeared and can \"git notes copy @{1}\" or\nsimilar for a note at the tip. Recovery for the intermediate commits\nis a little more… involved… as I'm sure you can imagine.\n\nAre notes out of scope for replay and history, or is this just a\n\"nobody's gotten around to it yet\"?\n\n-- \nD. Ben Knoble\n"},{"id":"549643","messageId":"anLXz2vos4zbIciW@pks.im","threadId":"66115","inReplyTo":"CALnO6CAN1=dgRsYjABfa3CJkGnvb139EcrzS9EnX43i3szOgtQ@mail.gmail.com","subject":"Re: git-replay/git-history lose notes","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-05T06:27:27Z","receivedAt":"2026-08-05T06:27:34Z","isPatch":false,"body":"Hi,\n\nOn Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote:\n> Hi all,\n> \n> I don't think this has been reported or discussed yet, though my\n> apologies if my search skills just didn't find it.\n> \n> It looks like git-replay and git-history will drop notes (or rather,\n> not carry them over) when rewriting history. I've seen this both with\n> \"git replay --onto=… …\" and \"git history fixup\" recently, though I\n> suspect it affects all the modes.\n> \n> Fortunately when I check range-diffs before pushing out new versions,\n> I notice notes have disappeared and can \"git notes copy @{1}\" or\n> similar for a note at the tip. Recovery for the intermediate commits\n> is a little more… involved… as I'm sure you can imagine.\n\nThis somehow rings a bell -- wasn't there a recent discussion about this\non the mailing list somewhere? I might be confusing it with a different\ncommand though that's loosing notes.\n\n> Are notes out of scope for replay and history, or is this just a\n> \"nobody's gotten around to it yet\"?\n\nFor git-replay(1) I'm not too sure, as I consider that command to be\npart of plumbing. But git-history(1) is a user-facing command, and\nbecause of that I think it should handle notes automatically for the\nuser.\n\nSo for me at least it's more of a \"nobody's gotten around to it yet\"\nscenario. I've created an issue in our GitLab issue tracker so that we\ncan maybe pick this up in the next release cycle. But I won't complain\nif anybody beats us to it :)\n\nThanks!\n\nPatrick\n"},{"id":"549678","messageId":"CALnO6CDtihFytS1dhfZPDA7jUL3bvAt=zYOH9Wi=naEoC58B1Q@mail.gmail.com","threadId":"66115","inReplyTo":"anLXz2vos4zbIciW@pks.im","subject":"Re: git-replay/git-history lose notes","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-05T11:39:25Z","receivedAt":"2026-08-05T11:39:38Z","isPatch":false,"body":"On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt wrote:\n>\n> Hi,\n>\n> On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote:\n> > Hi all,\n> >\n> > I don't think this has been reported or discussed yet, though my\n> > apologies if my search skills just didn't find it.\n> >\n> > It looks like git-replay and git-history will drop notes (or rather,\n> > not carry them over) when rewriting history. I've seen this both with\n> > \"git replay --onto=… …\" and \"git history fixup\" recently, though I\n> > suspect it affects all the modes.\n[snip]\n>\n> This somehow rings a bell -- wasn't there a recent discussion about this\n> on the mailing list somewhere? I might be confusing it with a different\n> command though that's loosing notes.\n\nYeah, that rings a bell for me, too. A peculiar rebase bug, I think?\n\n> > Are notes out of scope for replay and history, or is this just a\n> > \"nobody's gotten around to it yet\"?\n>\n> For git-replay(1) I'm not too sure, as I consider that command to be\n> part of plumbing. But git-history(1) is a user-facing command, and\n> because of that I think it should handle notes automatically for the\n> user.\n\nI can't speak for replay, although I do use it as a convenient \"rebase\na bunch of local branches that have conflicts without checking each\none out\"… but the history part makes sense to me.\n\n> So for me at least it's more of a \"nobody's gotten around to it yet\"\n> scenario. I've created an issue in our GitLab issue tracker so that we\n> can maybe pick this up in the next release cycle. But I won't complain\n> if anybody beats us to it :)\n>\n> Thanks!\n\nThank you!\n\n-- \nD. Ben Knoble\n"},{"id":"549690","messageId":"975a0661-945c-4a03-bad1-14db929c8d97@gmail.com","threadId":"66115","inReplyTo":"CALnO6CDtihFytS1dhfZPDA7jUL3bvAt=zYOH9Wi=naEoC58B1Q@mail.gmail.com","subject":"Re: git-replay/git-history lose notes","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-08-05T13:00:26Z","receivedAt":"2026-08-05T13:00:04Z","isPatch":false,"body":"On 05/08/2026 12:39, D. Ben Knoble wrote:\n> On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt wrote:\n>>\n>> Hi,\n>>\n>> On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote:\n>>> Hi all,\n>>>\n>>> I don't think this has been reported or discussed yet, though my\n>>> apologies if my search skills just didn't find it.\n>>>\n>>> It looks like git-replay and git-history will drop notes (or rather,\n>>> not carry them over) when rewriting history. I've seen this both with\n>>> \"git replay --onto=… …\" and \"git history fixup\" recently, though I\n>>> suspect it affects all the modes.\n> [snip]\n>>\n>> This somehow rings a bell -- wasn't there a recent discussion about this\n>> on the mailing list somewhere? I might be confusing it with a different\n>> command though that's loosing notes.\n> \n> Yeah, that rings a bell for me, too. A peculiar rebase bug, I think?\n\nYes, there was a note-related rebase bug reported recently\n\n>>> Are notes out of scope for replay and history, or is this just a\n>>> \"nobody's gotten around to it yet\"?\n>>\n>> For git-replay(1) I'm not too sure, as I consider that command to be\n>> part of plumbing. But git-history(1) is a user-facing command, and\n>> because of that I think it should handle notes automatically for the\n>> user.\n> \n> I can't speak for replay, although I do use it as a convenient \"rebase\n> a bunch of local branches that have conflicts without checking each\n> one out\"… but the history part makes sense to me.\n\nI think having a command line option for replay to turn on note copying \nwould be useful (and as a plumbing command we may not want the behavior \nchanging via config). The implementation will probably want to live in \nthe shared code anyway.\n\n>> So for me at least it's more of a \"nobody's gotten around to it yet\"\n>> scenario. I've created an issue in our GitLab issue tracker so that we\n>> can maybe pick this up in the next release cycle. But I won't complain\n>> if anybody beats us to it :)\n\nI agree adding it for history makes sense.\n\nThanks\n\nPhillip\n"},{"id":"549691","messageId":"xmqqv79osoqa.fsf@gitster.g","threadId":"66115","inReplyTo":"anLXz2vos4zbIciW@pks.im","subject":"Re: git-replay/git-history lose notes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-05T13:04:13Z","receivedAt":"2026-08-05T13:04:19Z","isPatch":false,"body":"Patrick Steinhardt writes:\n\n>> It looks like git-replay and git-history will drop notes (or rather,\n>> not carry them over) when rewriting history. I've seen this both with\n>> \"git replay --onto=… …\" and \"git history fixup\" recently, though I\n>> suspect it affects all the modes.\n>> \n>> Fortunately when I check range-diffs before pushing out new versions,\n>> I notice notes have disappeared and can \"git notes copy @{1}\" or\n>> similar for a note at the tip. Recovery for the intermediate commits\n>> is a little more… involved… as I'm sure you can imagine.\n>\n> This somehow rings a bell -- wasn't there a recent discussion about this\n> on the mailing list somewhere? I might be confusing it with a different\n> command though that's loosing notes.\n\nI recall mentioning the reason why rebase and cherry-pick behave\ndifferently with respect to notes, and why that is a good thing, but\nthat may not be what is ringing a bell for both of you.\n"},{"id":"549692","messageId":"CALnO6CAxr2+SV-1YrJBsb2LPqmzxnRSiPYXPqRQs384bwUO+mg@mail.gmail.com","threadId":"66115","inReplyTo":"975a0661-945c-4a03-bad1-14db929c8d97@gmail.com","subject":"Re: git-replay/git-history lose notes","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-05T13:05:00Z","receivedAt":"2026-08-05T13:05:13Z","isPatch":false,"body":"On Wed, Aug 5, 2026 at 9:00 AM Phillip Wood wrote:\n>\n> On 05/08/2026 12:39, D. Ben Knoble wrote:\n> > On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt wrote:\n> >>\n> >> Hi,\n> >>\n> >> On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote:\n[snip]\n> >>> Are notes out of scope for replay and history, or is this just a\n> >>> \"nobody's gotten around to it yet\"?\n> >>\n> >> For git-replay(1) I'm not too sure, as I consider that command to be\n> >> part of plumbing. But git-history(1) is a user-facing command, and\n> >> because of that I think it should handle notes automatically for the\n> >> user.\n> >\n> > I can't speak for replay, although I do use it as a convenient \"rebase\n> > a bunch of local branches that have conflicts without checking each\n> > one out\"… but the history part makes sense to me.\n>\n> I think having a command line option for replay to turn on note copying\n> would be useful (and as a plumbing command we may not want the behavior\n> changing via config). The implementation will probably want to live in\n> the shared code anyway.\n\nSee also notes.rewrite., perhaps? Although your point about\nconfig makes sense.\n\n-- \nD. Ben Knoble\n"},{"id":"549939","messageId":"CABPp-BHbWKr5tv9ApH8ZagJkY39XZgQbLoFrmQJfU71z1y6_xw@mail.gmail.com","threadId":"66115","inReplyTo":"CALnO6CAN1=dgRsYjABfa3CJkGnvb139EcrzS9EnX43i3szOgtQ@mail.gmail.com","subject":"Re: git-replay/git-history lose notes","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2026-08-07T06:53:07Z","receivedAt":"2026-08-07T06:53:20Z","isPatch":false,"body":"On Tue, Aug 4, 2026 at 1:06 PM D. Ben Knoble wrote:\n>\n> Hi all,\n>\n> I don't think this has been reported or discussed yet, though my\n> apologies if my search skills just didn't find it.\n>\n> It looks like git-replay and git-history will drop notes (or rather,\n> not carry them over) when rewriting history. I've seen this both with\n> \"git replay --onto=… …\" and \"git history fixup\" recently, though I\n> suspect it affects all the modes.\n>\n> Fortunately when I check range-diffs before pushing out new versions,\n> I notice notes have disappeared and can \"git notes copy @{1}\" or\n> similar for a note at the tip. Recovery for the intermediate commits\n> is a little more… involved… as I'm sure you can imagine.\n>\n> Are notes out of scope for replay and history, or is this just a\n> \"nobody's gotten around to it yet\"?\n\ngit filter-repo (and implicitly fast-export/fast-import) too, though\nthat one's a slightly bigger can of worms. (Trying to treat notes as\nthe underlying commits they are represented as is a really poor way to\nexport and import them; any filtering on the underlying commits will\ncause the notes that attach to them to just be lost since they will\ninstead attach to the original commit.)\n"},{"id":"549969","messageId":"anWpt6rzws0yYdFH@vader","threadId":"66115","inReplyTo":"CABPp-BHbWKr5tv9ApH8ZagJkY39XZgQbLoFrmQJfU71z1y6_xw@mail.gmail.com","subject":"Re: git-replay/git-history lose notes","fromName":"erik88","fromEmail":"erik88@gmail.com","sentAt":"2026-08-07T09:49:35Z","receivedAt":"2026-08-07T09:49:38Z","isPatch":false,"body":"On 06/08/26 23:53, Elijah Newren wrote:\n> git filter-repo (and implicitly fast-export/fast-import) too, though\n> that one's a slightly bigger can of worms. (Trying to treat notes as\n> the underlying commits they are represented as is a really poor way to\n> export and import them; any filtering on the underlying commits will\n> cause the notes that attach to them to just be lost since they will\n> instead attach to the original commit.)\n\nThere are some workarounds for filter-repo, IIRC they work _okay_.\n\nhttps://github.com/newren/git-filter-repo/issues/22#issuecomment-1834041470\n"},{"id":"550013","messageId":"CABPp-BFwbiasLBS3LDvaz736o2u0FkQJ73Tb8SQnc5rcR5Vn0A@mail.gmail.com","threadId":"66115","inReplyTo":"anWpt6rzws0yYdFH@vader","subject":"Re: git-replay/git-history lose notes","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2026-08-07T15:16:00Z","receivedAt":"2026-08-07T15:16:13Z","isPatch":false,"body":"On Fri, Aug 7, 2026 at 2:49 AM erik88 wrote:\n>\n> On 06/08/26 23:53, Elijah Newren wrote:\n> > git filter-repo (and implicitly fast-export/fast-import) too, though\n> > that one's a slightly bigger can of worms. (Trying to treat notes as\n> > the underlying commits they are represented as is a really poor way to\n> > export and import them; any filtering on the underlying commits will\n> > cause the notes that attach to them to just be lost since they will\n> > instead attach to the original commit.)\n>\n> There are some workarounds for filter-repo, IIRC they work _okay_.\n>\n> https://github.com/newren/git-filter-repo/issues/22#issuecomment-1834041470\n\nYes, I'm the one that added the \"workaround-available\" label on that\nticket. :-) Just thought the lack of built-in support (which would\nrequire fast-export & fast-import changes) and questions about ringing\nbells meant it might be an interesting tidbit to add.\n"}]}