From: Nico Williams <nico@cryptonector.com>
To: Martin von Zweigbergk <martinvonz@google.com>
Cc: Elijah Newren <newren@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Edwin Kempin <ekempin@google.com>,
Scott Chacon <scott@gitbutler.com>,
remo@buenzli.dev,
"philipmetzger@bluewin.ch" <philipmetzger@bluewin.ch>
Subject: Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer
Date: Thu, 3 Apr 2025 22:11:21 -0500 [thread overview]
Message-ID: <Z+9N2REkYZhrbkzb@ubby> (raw)
In-Reply-To: <CAESOdVAWWP=Rte4bx3zUZc6p0XiZaJS2OZr8ezRPkfq8K1TYfw@mail.gmail.com>
On Thu, Apr 03, 2025 at 03:47:30PM -0700, Martin von Zweigbergk wrote:
> I think part of the problem is that I didn't consider that Git doesn't
> really like to work in detached HEAD mode and doesn't automatically
> update refs pointing to rewritten commits. This does take away a lot
> of the usefulness, unfortunately. It would still be a bit useful as an
> argument to readonly commands.
I work in detached HEAD mode almost all the time. And yeah, Git won't
update refs when in detached HEAD mode because... what ref should it
update? The whole point of detached HEAD mode is that it does not.
> > What would `git switch <change ID>` do? `git switch` switches between
> > branches, but a change ID can't possibly identify a branch since many
> > commits could exist with the same change ID all in different branches.
>
> Yes, the same change id *can* exist on many branches, but it's pretty
> uncommon. It might happen after cherry-picking, depending on what we
The whole point of change IDs for me is that if I need to backport bug
fixes [0] then I can identify the bug fixes by change ID and then
cherry-pick them onto support branches, which means that yes, there will
be many commits with the same change ID, each on different branches.
Besides backports another use case that leaves multiple commits with the
same change ID is when I'm working on multiple different approaches to
implementing some feature on a complex codebase. I might have two or
three branches exploring different ways to implement some feature, and
of course I would want to use the same change IDs for similar commits
even if I didn't use cherry-pick to create all but the first.
Here's a third use-case that's quite real for me at $WORK where I have
repos for Debian-style packaging and use different branches for
different OS releases. Some such pkgs are ones that we patch locally,
so each release-specific branch targets a different OS release, but they
all mostly have the same contents, in which case this is similar to
backports. Other pkgs are locally developed and rarely differ on
different OS releases but occasionally they have to for <reasons> --
this is not similar to backports.
[0] Granted, the industry has moved away from backports. But many open
source projects still backport security fixes. E.g., OpenSSL,
PostgreSQL, etc. So this is relevant.
> decide there, but it should very rarely happen in other cases. When
> you rewrite a commit, the old commit usually becomes unreachable, so
> if your change id resolved to one commit before the rewrite, then it
> will resolve to one commit after the rewrite. [...]
No matter what you will not have a guarantee of one commit for any given
change ID. Therefore `git switch $change_id` is not workable, not
without interaction, and even then still not workable because Git might
have to search _many_ branches to find commits matching the given change
ID. (Fossil could have an index on change ID and trivially make that
search possible, but for Git adding an index is more complicated.)
> > I'd expect many commits with the same change ID in a _repo_, but at most
> > one in a _branch_.
>
> There may be multiple commits with the same change ID in a repo if you
> had cherry-picked the commit, depending on what we decide to do with
> the change ID on cherry-pick. But cherry-picks are not very common
> anyway. Or maybe it's common in some workflow? Oh, are you thinking of
> a scenario where you cherry-pick your own commit to see if an
> alternative approach is better? Sure, if cherry-pick preserve the
> change ID, then you would have multiple commits with the same change
> ID in that case.
Even if cherry-picking were not common it's supported, therefore you
can't have change IDs be unique like this. That doesn't make change IDs
useless -- on the contrary, their utility comes from the fact that they
are not repo-wide unique!
Nico
--
next prev parent reply other threads:[~2025-04-04 3:28 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 18:48 Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer Martin von Zweigbergk
2025-04-02 19:34 ` Remo Senekowitsch
2025-04-02 19:49 ` Konstantin Ryabitsev
2025-04-02 19:45 ` Konstantin Ryabitsev
2025-04-02 19:52 ` Martin von Zweigbergk
2025-04-03 9:09 ` Patrick Steinhardt
2025-04-03 10:38 ` Remo Senekowitsch
2025-04-03 11:06 ` Patrick Steinhardt
2025-04-03 15:56 ` Elijah Newren
2025-04-03 16:25 ` Remo Senekowitsch
2025-04-03 16:38 ` Elijah Newren
2025-04-03 21:46 ` Martin von Zweigbergk
2025-04-04 9:41 ` Patrick Steinhardt
2025-04-03 15:39 ` Elijah Newren
2025-04-03 16:40 ` Remo Senekowitsch
2025-04-03 22:11 ` Kane York
2025-04-04 2:28 ` Elijah Newren
2025-04-04 2:40 ` Elijah Newren
2025-04-04 3:47 ` Martin von Zweigbergk
2025-04-04 4:03 ` Nico Williams
2025-04-04 4:59 ` Elijah Newren
2025-04-04 5:21 ` Martin von Zweigbergk
2025-04-04 9:29 ` Patrick Steinhardt
2025-04-03 17:48 ` Theodore Ts'o
2025-04-03 20:31 ` Remo Senekowitsch
2025-04-05 2:09 ` Theodore Ts'o
2025-04-03 18:10 ` Nico Williams
2025-04-03 21:45 ` Remo Senekowitsch
[not found] ` <Z+8GoNrdaJlmNpGm@ubby>
2025-04-04 0:05 ` Remo Senekowitsch
2025-04-04 3:52 ` Nico Williams
2025-04-04 7:41 ` Remo Senekowitsch
2025-04-04 16:08 ` Nico Williams
2025-04-03 22:05 ` Martin von Zweigbergk
2025-04-03 22:13 ` Nico Williams
2025-04-03 22:47 ` Martin von Zweigbergk
2025-04-04 2:06 ` Elijah Newren
2025-04-04 3:11 ` Nico Williams [this message]
2025-04-04 4:08 ` Martin von Zweigbergk
2025-04-04 4:23 ` Nico Williams
2025-04-04 9:34 ` Patrick Steinhardt
2025-04-04 16:04 ` Nico Williams
2025-04-07 8:00 ` Patrick Steinhardt
2025-04-07 20:59 ` Junio C Hamano
2025-04-07 21:36 ` Nico Williams
2025-04-08 12:55 ` Theodore Ts'o
2025-04-08 15:53 ` Nico Williams
2025-04-09 12:19 ` Theodore Ts'o
2025-04-09 12:56 ` Junio C Hamano
2025-04-09 19:13 ` Nico Williams
2025-04-10 8:29 ` Junio C Hamano
2025-04-10 21:40 ` Martin von Zweigbergk
2025-04-09 16:54 ` Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer) Nico Williams
2025-04-09 18:02 ` Junio C Hamano
2025-04-09 18:35 ` Nico Williams
2025-04-09 19:14 ` Eric Sunshine
2025-04-09 19:31 ` Nico Williams
2025-04-10 13:44 ` Theodore Ts'o
2025-04-10 16:18 ` Junio C Hamano
2025-04-11 15:48 ` Theodore Ts'o
2025-04-11 16:38 ` Konstantin Ryabitsev
2025-04-11 17:44 ` Junio C Hamano
2025-04-12 23:13 ` Theodore Ts'o
2025-04-14 15:13 ` Junio C Hamano
2025-04-15 22:30 ` Remo Senekowitsch
2025-04-16 0:09 ` Junio C Hamano
2025-04-16 0:21 ` Jacob Keller
2025-04-15 21:38 ` Jacob Keller
2025-04-14 19:54 ` D. Ben Knoble
2025-04-14 21:34 ` Nico Williams
2025-04-15 21:44 ` Jacob Keller
2025-04-16 11:36 ` Remo Senekowitsch
2025-04-22 20:17 ` D. Ben Knoble
2025-04-22 22:24 ` Remo Senekowitsch
2025-04-22 22:42 ` Junio C Hamano
2025-04-22 22:51 ` Nico Williams
2025-04-22 23:47 ` Remo Senekowitsch
2025-04-23 0:32 ` Nico Williams
2025-04-23 1:15 ` Remo Senekowitsch
2025-04-23 4:45 ` Nico Williams
2025-04-22 23:49 ` Junio C Hamano
2025-04-23 1:02 ` Nico Williams
2025-04-23 4:47 ` Nico Williams
2025-04-22 23:21 ` Remo Senekowitsch
2025-04-23 5:07 ` Martin von Zweigbergk
2025-04-23 15:51 ` Junio C Hamano
2025-04-23 16:19 ` Martin von Zweigbergk
2025-06-06 13:04 ` Toon Claes
[not found] ` <aAgWytQNqtLzg2TU@ubby>
2025-04-23 0:25 ` Remo Senekowitsch
2025-04-23 0:45 ` Nico Williams
2025-04-23 12:58 ` How GitLab does/doesn't need change IDs (was Re: Semantics of change IDs) Toon Claes
2025-04-23 18:59 ` Nico Williams
2025-05-10 19:32 ` Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer) D. Ben Knoble
2025-05-10 19:46 ` D. Ben Knoble
2025-05-10 20:31 ` Martin von Zweigbergk
2025-05-12 17:03 ` Junio C Hamano
2025-05-12 17:19 ` Martin von Zweigbergk
2025-05-14 14:38 ` Junio C Hamano
2025-05-15 10:31 ` Oswald Buddenhagen
2025-05-15 16:32 ` Jacob Keller
2025-05-15 19:59 ` Junio C Hamano
2025-05-15 20:10 ` Nico Williams
[not found] ` <aCJi+4q6DZhnfdy+@ubby>
2025-05-12 21:43 ` Martin von Zweigbergk
2025-05-12 22:04 ` brian m. carlson
2025-06-06 12:28 ` Toon Claes
2025-06-06 15:44 ` Junio C Hamano
2025-05-13 21:22 ` D. Ben Knoble
2025-04-07 22:51 ` Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer Remo Senekowitsch
2025-04-08 0:10 ` Junio C Hamano
2025-04-08 5:35 ` Martin von Zweigbergk
2025-04-08 14:27 ` Junio C Hamano
2025-04-08 15:58 ` Phillip Wood
2025-04-08 16:27 ` Nico Williams
2025-04-12 21:32 ` Junio C Hamano
2025-04-16 0:24 ` Jacob Keller
2025-05-14 15:08 ` Kristoffer Haugsbakk
2025-04-08 14:27 ` Junio C Hamano
2025-08-19 14:04 ` Askar Safin
2025-08-19 16:44 ` Ben Knoble
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=Z+9N2REkYZhrbkzb@ubby \
--to=nico@cryptonector.com \
--cc=ekempin@google.com \
--cc=git@vger.kernel.org \
--cc=martinvonz@google.com \
--cc=newren@gmail.com \
--cc=philipmetzger@bluewin.ch \
--cc=remo@buenzli.dev \
--cc=scott@gitbutler.com \
/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;
as well as URLs for NNTP newsgroup(s).