...to track evolution of a patch through time. tl;dr: How hard would it be to retrofit an 'ChangeID' concept à la the 'Change- ID' trailer used by Gerrit into git core? Firstly, apologies in advance if this is the wrong forum to post a feature request. I help maintain the Patchwork project [1], which a web-based tool that provides a mechanism to track the state of patches submitted to a mailing list and make sure stuff doesn't slip through the crack. One of our long-term goals has been to track the evolution of an individual patch through multiple revisions. This is surprisingly hard goal because oftentimes there isn't a whole lot to work with. One can try to guess whether things are the same by inspecting the metadata of the commit (subject, author, commit message, and the diff itself) but each of these metadata items are subject to arbitrary changes and are therefore fallible. One of the mechanisms I've seen used to address this is the 'Change-ID' trailer used by Gerrit. For anyone that hasn't seen this, the Gerrit server provides a git commit hook that you can install locally. When installed, this appends a 'Change-ID' trailer to each and every commit message. In this way, the evolution of a patch (or a "change", in Gerrit parlance) can be tracked through time since the Change ID provides an authoritative answer to the question "is this still the same patch". Unfortunately, there are still some obvious downside to this approach. Not only does this additional trailer clutter your commit messages but it's also something the user must install themselves. While Gerrit can insist that this is installed before pushing a change, this isn't an option for any of the common forges nor is it something git-send-email supports. I imagine most people working with mailing list based workflows have their own client side tooling to support this while software forges like GitHub and GitLab simply don't bother tracking version history between individual commits in a pull/merge request. IMO though, it would be fantastic if third party tools weren't necessary though. What I suspect we want is a persistent ID (or rather UUID) that never changes regardless of how many times a patch is cherry-picked, rebased, or otherwise modified, similar to the Author and AuthorDate fields. Like Author and AuthorDate, it would be part of the core git commit metadata rather than something in the commit message like Signed-Off-By or Change-ID. Has such an idea ever been explored? Is it even possible? Would it be broadly useful? Cheers, Stephen [1] github.com/getpatchwork/patchwork/
