Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer
On Thu, 03 Apr 2025 18:40:20 +0200, Remo Senekowitsch wrote:
Show 5 quoted lines
> On Thu Apr 3, 2025 at 5:39 PM CEST, Elijah Newren wrote:
>> 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.
Show 19 quoted lines
> I'd say Jujutsu, Gerrit and GitButler think of a change-id as associated with
> a unit of review.
>
> [...]
>
> Cherry-picking on the other hand often represents a separate unit of review.
> That review may revolve around whether it makes sense to backport a bugfix at
> all or any additional changes that may have been necessary to make the bugfix
> work in the different, older codebase.
>
> As mentioned above, there's also the issue that preserving the change-id on
> cherry-pick likely results in duplicates. For Jujutsu, it would be nice it
> this was avoided. But it's not infeasible to deal with that either.
>
> For Gerrit, it would be important to be able to track a change across
> cherry-picks somehow, since that is a feature they already have. If Git
> decides to preserve the change-id on cherry-pick, there's no problem for
> Gerrit. Alternatives include storing a separate cherry-picked-from header or
> enabling the -x flag on cherry-pick by default.
I agree, and propose this concrete behavior:
- git cherry-pick generates a fresh `change-id`, and places the old change-id
in a `cherry-picked-change` header
- git cherry-pick preserves the old `change-id` if passed the new
`--preserve-change-id` flag
- git rebase passes the `--preserve-change-id` flag on 'pick' actions, unless
passed the new `--no-preserve-change-id` flag
- git rebase uses the earlier commit's change-id on 'fixup' actions
- git rebase prints the change-ids into the COMMIT_MSG on 'squash' actions, and
tries to read the user's choice of which to use, defaulting to the earlier
commit if both or none are present
- git rebase creates a new change-id on 'merge' actions
- git rebase needs no special behavior specified for 'edit', 'exec', 'break',
'drop', 'label', 'reset', 'update-ref'