Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer
- From
- Nico Williams <nico@cryptonector.com>
- Date
- Apr 3, 2025, 18:10 UTC
- Message-ID
- <Z+7PDi5y4wXJBK4r@ubby>
- In-Reply-To
- <CABPp-BFRz-yjnti4W17AEBozb0v52kmNsgTLUZW6-MF34R-xdw@mail.gmail.com>
On Thu, Apr 03, 2025 at 08:39:31AM -0700, Elijah Newren wrote:
Show 13 quoted lines
> On Wed, Apr 2, 2025 at 11:48 AM Martin von Zweigbergk > > There are many benefits to having a change id even if it's just > > local. I mentioned some in my email to this mailing list in [1]. > > For example, it enables > > `git rebase main <change ID>; git switch <change ID>` without > > requiring the user to look up the hash of the rewritten commit. > > But <change ID> isn't unique, right? The whole point of having the > change ID is to preserve it despite edits (e.g. rebase, commit > --amend, cherry-pick), meaning that you end up with multiple commits > with the same <change ID>. > > Why would this work?
I agree that `git rebase main <change ID>; git switch <change ID>` is not a good UI, and I wouldn't want it even though I want change IDs.
Change IDs are documentary, and they help people understand that various commits are just edits/rewrites of the same original commit.
> And if it does work, isn't it expensive since you'd need to walk > history to find it? Or do you keep an extra lookup table on the side > somewhere?
Worse: since there can be many commits with the same change ID they can't be used as refs because Git can't possibly be expected to find _the one_ you really intend -- how could it? I suppose Git could let you pick from a list, but that's not likely going to have enough context. Maybe Git could give you a list of named branches in which it found some change ID's commits to pick one branch from, or maybe one could `git cherry-pick --from $some_branch $cid` and have Git find the commit(s) on `$some_branch` that match change ID `$cid`.
Also, maybe commits need to support multiple change IDs. For example, one might want one change ID for a set of commits (eg implementing a feature), and each commit in the set having a second and more unique change ID for just that commit (and all edits/rewrites of it).
> Yaay, I always hated it as a trailer.
More headers is better.
Show 5 quoted lines
> cherry-pick & rebase preserve author name, email & time, while > creating a new committer name, email, & time. To me, the change-id is > about the authorship, and since these commands already preserve > authorship, it'd seem weird to me to have cherry-pick not preserve the > change-id by default.
+1. Besides, rebase is just a a bunch of cherry-picks, so cherry-pick is the fundamental operation here. If rebase is to preserver change-id then so is cherry-pick.
Nico