git-replay/git-history lose notes
9 messages between Aug 4, 2026 and Aug 7, 2026, from D. Ben Knoble, Patrick Steinhardt, Phillip Wood, Junio C Hamano, Elijah Newren, erik88.
Plain Markdown or JSON for tools and agents.
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
Re: git-replay/git-history lose notes
Hi,
On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote:
Show 14 quoted lines
> 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
Re: git-replay/git-history lose notes
On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt <ps@pks.im> wrote:
Show 13 quoted lines
>
> 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.
>
> 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?
Show 7 quoted lines
> > 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.
Show 6 quoted lines
> 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!
--
D. Ben Knoble
Re: git-replay/git-history lose notes
On 05/08/2026 12:39, D. Ben Knoble wrote:
Show 21 quoted lines
> On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt <ps@pks.im> 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
Show 11 quoted lines
>>> 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
Re: git-replay/git-history lose notes
Patrick Steinhardt <ps@pks.im> writes:
Show 13 quoted lines
>> 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.
Re: git-replay/git-history lose notes
On Wed, Aug 5, 2026 at 9:00 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
Show 7 quoted lines
>
> On 05/08/2026 12:39, D. Ben Knoble wrote:
> > On Wed, Aug 5, 2026 at 2:27 AM Patrick Steinhardt <ps@pks.im> wrote:
> >>
> >> Hi,
> >>
> >> On Tue, Aug 04, 2026 at 04:06:38PM -0400, D. Ben Knoble wrote:
Show 16 quoted lines
> >>> 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.<command>, perhaps? Although your point about config makes sense.
--
D. Ben Knoble
Re: git-replay/git-history lose notes
On Tue, Aug 4, 2026 at 1:06 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:
Show 18 quoted lines
>
> 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.)
Re: git-replay/git-history lose notes
On 06/08/26 23:53, Elijah Newren wrote:
Show 6 quoted lines
> 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
Re: git-replay/git-history lose notes
On Fri, Aug 7, 2026 at 2:49 AM erik88 <erik88@gmail.com> wrote:
Show 12 quoted lines
>
> 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.