From: Taylor Blau <me@ttaylorr•com>
To: git@vger•kernel.org
Subject: [NOTES 07/11] Change-ID Header in Git
Date: Mon, 6 Oct 2025 15:19:54 -0400 [thread overview]
Message-ID: <aOQWWkj/q7GfKZY7@nand.local> (raw)
In-Reply-To: <aOQVeVYY6zadPjln@nand.local>
Topic: Change-ID Header in Git
Leader: Philip Metzger
* How do we store the Change-ID? Store it in a header? Some auxiliary metadata
store?
* Happens to work in a header for GitHub because they survive rebases since
GitHub uses replay, not all forges do this.
* Want a standard interoperable way to associate Change-IDs with commits.
* Storage discussion has largely been covered.
* Taylor: what's less clear to me is the semantics of when we keep Change-IDs
across operations, when we assign new ones.
* Cherry-picking equivalent assign a new Change-ID
* Almost everything else retains that Change-ID
* Taylor: we need to agree on the storage, but not necessarily on the semantics
of when we keep versus assign new Change-IDs.
* Caleb: Assigning a new Change-ID when cherry-picking is interesting, since we
(GitButler) retain those.
* Philip: Gerrit does the same thing, but JJ does something differently. Their
approach was to have an optional header that describes the “origin” (in some
sense) of the commit.
* Caleb: I wonder if the semantics are important if we are trying to use these
in the same sandbox?
* Taylor: we need to understand and agree on them when we are working on the
same repository (regardless of using the same tool), but not in general at
the tool level.
* What's the next step?
* Martin: experiment with it, see if we like the semantics. Don't want to
emphasize the divergence table.
* Taylor: do we need a version associated with the change-id? Philip: no, we
treat it as an opaque identifier, versioning not necessary.
* Elijah: given that multiple players want this and have agreed on a common way
to represent it, maybe we'll have a more productive discussion on it in a year
after they've experienced working with that header for a year
* Jonathan: does it matter what forges do with automatic squash/rebase?
* Philip: for JJ we don't want to use that information, but we're just
another Git client in the ecosystem, so that's just our perspective.
* Martin: Should there be agreement on the semantics?
* Elijah: depends on the usage.
* Elijah: semantics get fuzzy because of splitting and merging, so not clear
what to do there. We either need to clarify it, but probably not here.
next prev parent reply other threads:[~2025-10-06 19:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 19:16 Notes from the Git Contributor's Summit, 2025 Taylor Blau
2025-10-06 19:18 ` [NOTES 01/11] SHA-256 and interoperability work Taylor Blau
2025-10-06 19:18 ` [NOTES 02/11] First-class conflicts in Git? Taylor Blau
2025-10-06 19:18 ` [NOTES 03/11] The future of history rewriting - rebase, replay and history (+Change-IDs) Taylor Blau
2025-10-06 19:18 ` [NOTES 04/11] Rust Taylor Blau
2025-10-06 19:19 ` [NOTES 05/11] Pluggable object databases Taylor Blau
2025-10-06 19:19 ` [NOTES 06/11] Repository maintenance long-term goals Taylor Blau
2025-10-06 19:19 ` Taylor Blau [this message]
2025-10-06 19:20 ` [NOTES 08/11] Resumable fetch / push Taylor Blau
2025-10-06 19:20 ` [NOTES 09/11] Git 3.0 Taylor Blau
2025-10-06 19:20 ` [NOTES 10/11] How can companies respectfully engage contractors to work on Git? Taylor Blau
2025-10-06 19:20 ` [NOTES 11/11] Conservancy 2025 updates Taylor Blau
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=aOQWWkj/q7GfKZY7@nand.local \
--to=me@ttaylorr$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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