Change IDs for kernel patches [LWN.net]

Change IDs for kernel patches

Posted Sep 1, 2019 15:08 UTC (Sun) by glasserc (subscriber, #108472)
Parent article: Change IDs for kernel patches

This discussion is interesting, but I wish it didn't focus on the specific use case of code review for the Linux kernel. Any git project where feature branches are revised and shared over time could benefit from having links from one version of a commit to a previous one. I've often wished Git had something like Mercurial's "obsolesence markers" (from the "changeset evolution" extension). From my (non-kernel) perspective, the question of how these links are serialized into emails is not very important, but having them enables a bunch of other features.

to post comments

History of the history

Posted Sep 5, 2019 9:33 UTC (Thu) by marcH (subscriber, #57642) [Link]

> Any git project where feature branches are revised and shared over time could benefit from having links from one version of a commit to a previous one.

The tool laser-focused on the "history of the history" is https://github.com/git-series/git-series

Unlike email, all tools specialized for code review implement some form of linking between revisions in their database. While such linking is one of the most basic code review features, there are surprisingly big differences between the approaches.

Gerrit (obviously) supports this well for individual patches but doesn't treat series as a "first-class" citizens, patches in a series are just "related":
https://gerrit-review.googlesource.com/Documentation/user... Trying for instance to see how a series has been re-ordered is close to impossible with that user interface. I just fetch the two revisions and compare with git locally.

On the other hand Gerrit's ability to filter out rebase noise has become as impressive as git series': https://bugs.chromium.org/p/gerrit/issues/detail?id=217#c42

Github is probably the worse at this. Series are first-class citizens but the recommended workflow is to never rewrite anything and always add the equivalent of fixup! commits until the review is finished - except there's no way to mark which commit is a fixup for what. Force pushes are possible but break a number of features. More details and references at https://github.com/zephyrproject-rtos/zephyr/pull/14444

Gitlab follows github's model but seems to cope with force pushes much better.