Git development
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: "D. Ben Knoble" <ben.knoble@gmail.com>, Patrick Steinhardt <ps@pks.im>
Cc: Git <git@vger.kernel.org>, Elijah Newren <newren@gmail.com>
Subject: Re: git-replay/git-history lose notes
Date: Wed, 5 Aug 2026 14:00:26 +0100	[thread overview]
Message-ID: <975a0661-945c-4a03-bad1-14db929c8d97@gmail.com> (raw)
In-Reply-To: <CALnO6CDtihFytS1dhfZPDA7jUL3bvAt=zYOH9Wi=naEoC58B1Q@mail.gmail.com>

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:
>>> 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

  reply	other threads:[~2026-08-05 13:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 20:06 git-replay/git-history lose notes D. Ben Knoble
2026-08-05  6:27 ` Patrick Steinhardt
2026-08-05 11:39   ` D. Ben Knoble
2026-08-05 13:00     ` Phillip Wood [this message]
2026-08-05 13:05       ` D. Ben Knoble
2026-08-05 13:04   ` Junio C Hamano
2026-08-07  6:53 ` Elijah Newren
2026-08-07  9:49   ` erik88
2026-08-07 15:16     ` Elijah Newren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=975a0661-945c-4a03-bad1-14db929c8d97@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox