Hi, Vagrant Cascadian <vagr...@debian.org> writes:
> On 2023-09-09, Maxim Cournoyer wrote: >> Vagrant Cascadian <vagr...@debian.org> writes: >>>> Did you see my message about integrating a commit-hook similar to what >>>> Gerrit uses? It produces unique ID such as: >>>> >>>> --8<---------------cut here---------------start------------->8--- >>>> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0 >>>> --8<---------------cut here---------------end--------------->8--- > ... >>> That seems like it would only work if the patch was identical, as >>> opposed to a slightly rebased patch on top of newer patches on master? >>> >>> How can you correlate Change-Id to a patch in the tracker? >> >> The Change-Id stays the same unless you manually edit it out of your >> commit message when amending / rebasing, so the commit hash may change >> while the Change-Id stays the same. So you can rebase your feature >> branch on master and share a v2, whose existing commits will have the >> same Change-Ids (newly added commits would get their own Change-Id >> trailer). > > Ok, that makes some sense. > > Although the majority of bugs in the cleanup work I did were actually > filed by someone else entirely... so the Change-Id will not help with > those. Not a reason not to implement it, but not consistent with some of > the triggers of this thread. :) I doubt the Change-Id idea would help much closing *bugs* on the bug-guix tracker, but I'd expect it to be useful to close already merged (but forgotten on the guix-patches tracker) *patches*. The Change-Ids would be added automatically without the user having to install anything, so from the time it's deployed we'd have a means to identify which patch series were all merged. -- Thanks, Maxim
