# git-replay/git-history lose notes 9 messages from 2026-08-04 to 2026-08-07. Participants: D. Ben Knoble, Patrick Steinhardt, Phillip Wood, Junio C Hamano, Elijah Newren, erik88. Thread: https://gitlist.dev/t/66115 ## D. Ben Knoble, 2026-08-04 20:06 Subject: git-replay/git-history lose notes Message-ID: ``` Hi all, I don't think this has been reported or discussed yet, though my apologies if my search skills just didn't find it. It looks like git-replay and git-history will drop notes (or rather, not carry them over) when rewriting history. I've seen this both with "git replay --onto=… …" and "git history fixup" recently, though I suspect it affects all the modes. Fortunately when I check range-diffs before pushing out new versions, I notice notes have disappeared and can "git notes copy @{1}" or similar for a note at the tip. Recovery for the intermediate commits is a little more… involved… as I'm sure you can imagine. Are notes out of scope for replay and history, or is this just a "nobody's gotten around to it yet"? -- D. Ben Knoble ``` ## Patrick Steinhardt, 2026-08-05 06:27 Subject: Re: git-replay/git-history lose notes Message-ID: In-Reply-To: ``` Hi, On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote: > Hi all, > > I don't think this has been reported or discussed yet, though my > apologies if my search skills just didn't find it. > > It looks like git-replay and git-history will drop notes (or rather, > not carry them over) when rewriting history. I've seen this both with > "git replay --onto=… …" and "git history fixup" recently, though I > suspect it affects all the modes. > > Fortunately when I check range-diffs before pushing out new versions, > I notice notes have disappeared and can "git notes copy @{1}" or > similar for a note at the tip. Recovery for the intermediate commits > is a little more… involved… as I'm sure you can imagine. This somehow rings a bell -- wasn't there a recent discussion about this on the mailing list somewhere? I might be confusing it with a different command though that's loosing notes. > Are notes out of scope for replay and history, or is this just a > "nobody's gotten around to it yet"? For git-replay(1) I'm not too sure, as I consider that command to be part of plumbing. But git-history(1) is a user-facing command, and because of that I think it should handle notes automatically for the user. So for me at least it's more of a "nobody's gotten around to it yet" scenario. I've created an issue in our GitLab issue tracker so that we can maybe pick this up in the next release cycle. But I won't complain if anybody beats us to it :) Thanks! Patrick ``` ## D. Ben Knoble, 2026-08-05 11:39 Subject: Re: git-replay/git-history lose notes Message-ID: In-Reply-To: ``` On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt wrote: > > Hi, > > On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote: > > Hi all, > > > > I don't think this has been reported or discussed yet, though my > > apologies if my search skills just didn't find it. > > > > It looks like git-replay and git-history will drop notes (or rather, > > not carry them over) when rewriting history. I've seen this both with > > "git replay --onto=… …" and "git history fixup" recently, though I > > suspect it affects all the modes. [snip] > > This somehow rings a bell -- wasn't there a recent discussion about this > on the mailing list somewhere? I might be confusing it with a different > command though that's loosing notes. Yeah, that rings a bell for me, too. A peculiar rebase bug, I think? > > Are notes out of scope for replay and history, or is this just a > > "nobody's gotten around to it yet"? > > For git-replay(1) I'm not too sure, as I consider that command to be > part of plumbing. But git-history(1) is a user-facing command, and > because of that I think it should handle notes automatically for the > user. I can't speak for replay, although I do use it as a convenient "rebase a bunch of local branches that have conflicts without checking each one out"… but the history part makes sense to me. > So for me at least it's more of a "nobody's gotten around to it yet" > scenario. I've created an issue in our GitLab issue tracker so that we > can maybe pick this up in the next release cycle. But I won't complain > if anybody beats us to it :) > > Thanks! Thank you! -- D. Ben Knoble ``` ## Phillip Wood, 2026-08-05 13:00 Subject: Re: git-replay/git-history lose notes Message-ID: <975a0661-945c-4a03-bad1-14db929c8d97@gmail.com> In-Reply-To: ``` On 05/08/2026 12:39, D. Ben Knoble wrote: > On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt wrote: >> >> Hi, >> >> On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote: >>> Hi all, >>> >>> I don't think this has been reported or discussed yet, though my >>> apologies if my search skills just didn't find it. >>> >>> It looks like git-replay and git-history will drop notes (or rather, >>> not carry them over) when rewriting history. I've seen this both with >>> "git replay --onto=… …" and "git history fixup" recently, though I >>> suspect it affects all the modes. > [snip] >> >> This somehow rings a bell -- wasn't there a recent discussion about this >> on the mailing list somewhere? I might be confusing it with a different >> command though that's loosing notes. > > Yeah, that rings a bell for me, too. A peculiar rebase bug, I think? Yes, there was a note-related rebase bug reported recently >>> Are notes out of scope for replay and history, or is this just a >>> "nobody's gotten around to it yet"? >> >> For git-replay(1) I'm not too sure, as I consider that command to be >> part of plumbing. But git-history(1) is a user-facing command, and >> because of that I think it should handle notes automatically for the >> user. > > I can't speak for replay, although I do use it as a convenient "rebase > a bunch of local branches that have conflicts without checking each > one out"… but the history part makes sense to me. I think having a command line option for replay to turn on note copying would be useful (and as a plumbing command we may not want the behavior changing via config). The implementation will probably want to live in the shared code anyway. >> So for me at least it's more of a "nobody's gotten around to it yet" >> scenario. I've created an issue in our GitLab issue tracker so that we >> can maybe pick this up in the next release cycle. But I won't complain >> if anybody beats us to it :) I agree adding it for history makes sense. Thanks Phillip ``` ## Junio C Hamano, 2026-08-05 13:04 Subject: Re: git-replay/git-history lose notes Message-ID: In-Reply-To: ``` Patrick Steinhardt writes: >> It looks like git-replay and git-history will drop notes (or rather, >> not carry them over) when rewriting history. I've seen this both with >> "git replay --onto=… …" and "git history fixup" recently, though I >> suspect it affects all the modes. >> >> Fortunately when I check range-diffs before pushing out new versions, >> I notice notes have disappeared and can "git notes copy @{1}" or >> similar for a note at the tip. Recovery for the intermediate commits >> is a little more… involved… as I'm sure you can imagine. > > This somehow rings a bell -- wasn't there a recent discussion about this > on the mailing list somewhere? I might be confusing it with a different > command though that's loosing notes. I recall mentioning the reason why rebase and cherry-pick behave differently with respect to notes, and why that is a good thing, but that may not be what is ringing a bell for both of you. ``` ## D. Ben Knoble, 2026-08-05 13:05 Subject: Re: git-replay/git-history lose notes Message-ID: In-Reply-To: <975a0661-945c-4a03-bad1-14db929c8d97@gmail.com> ``` On Wed, Aug 5, 2026 at 9:00 AM Phillip Wood wrote: > > On 05/08/2026 12:39, D. Ben Knoble wrote: > > On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt wrote: > >> > >> Hi, > >> > >> On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote: [snip] > >>> Are notes out of scope for replay and history, or is this just a > >>> "nobody's gotten around to it yet"? > >> > >> For git-replay(1) I'm not too sure, as I consider that command to be > >> part of plumbing. But git-history(1) is a user-facing command, and > >> because of that I think it should handle notes automatically for the > >> user. > > > > I can't speak for replay, although I do use it as a convenient "rebase > > a bunch of local branches that have conflicts without checking each > > one out"… but the history part makes sense to me. > > I think having a command line option for replay to turn on note copying > would be useful (and as a plumbing command we may not want the behavior > changing via config). The implementation will probably want to live in > the shared code anyway. See also notes.rewrite., perhaps? Although your point about config makes sense. -- D. Ben Knoble ``` ## Elijah Newren, 2026-08-07 06:53 Subject: Re: git-replay/git-history lose notes Message-ID: In-Reply-To: ``` On Tue, Aug 4, 2026 at 1:06 PM D. Ben Knoble wrote: > > Hi all, > > I don't think this has been reported or discussed yet, though my > apologies if my search skills just didn't find it. > > It looks like git-replay and git-history will drop notes (or rather, > not carry them over) when rewriting history. I've seen this both with > "git replay --onto=… …" and "git history fixup" recently, though I > suspect it affects all the modes. > > Fortunately when I check range-diffs before pushing out new versions, > I notice notes have disappeared and can "git notes copy @{1}" or > similar for a note at the tip. Recovery for the intermediate commits > is a little more… involved… as I'm sure you can imagine. > > Are notes out of scope for replay and history, or is this just a > "nobody's gotten around to it yet"? git filter-repo (and implicitly fast-export/fast-import) too, though that one's a slightly bigger can of worms. (Trying to treat notes as the underlying commits they are represented as is a really poor way to export and import them; any filtering on the underlying commits will cause the notes that attach to them to just be lost since they will instead attach to the original commit.) ``` ## erik88, 2026-08-07 09:49 Subject: Re: git-replay/git-history lose notes Message-ID: In-Reply-To: ``` On 06/08/26 23:53, Elijah Newren wrote: > git filter-repo (and implicitly fast-export/fast-import) too, though > that one's a slightly bigger can of worms. (Trying to treat notes as > the underlying commits they are represented as is a really poor way to > export and import them; any filtering on the underlying commits will > cause the notes that attach to them to just be lost since they will > instead attach to the original commit.) There are some workarounds for filter-repo, IIRC they work _okay_. https://github.com/newren/git-filter-repo/issues/22#issuecomment-1834041470 ``` ## Elijah Newren, 2026-08-07 15:16 Subject: Re: git-replay/git-history lose notes Message-ID: In-Reply-To: ``` On Fri, Aug 7, 2026 at 2:49 AM erik88 wrote: > > On 06/08/26 23:53, Elijah Newren wrote: > > git filter-repo (and implicitly fast-export/fast-import) too, though > > that one's a slightly bigger can of worms. (Trying to treat notes as > > the underlying commits they are represented as is a really poor way to > > export and import them; any filtering on the underlying commits will > > cause the notes that attach to them to just be lost since they will > > instead attach to the original commit.) > > There are some workarounds for filter-repo, IIRC they work _okay_. > > https://github.com/newren/git-filter-repo/issues/22#issuecomment-1834041470 Yes, I'm the one that added the "workaround-available" label on that ticket. :-) Just thought the lack of built-in support (which would require fast-export & fast-import changes) and questions about ringing bells meant it might be an interesting tidbit to add. ```