Git evolve: tracking changes to changes

submited by
Style Pass
2023-03-17 15:30:12 is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

By Jonathan Corbet November 11, 2022 The Git source-code management system exists to track changes to a set of files; the stream of commits in a Git repository reflects the change history of those files. What is seen in Git, though, is the final form of those commits; the changes that the patches themselves went through on their way toward acceptance are not shown there. That history can have value, especially while changes are still under consideration. The proposed git evolve subcommand is a recognition that changes themselves go through changes and that this process might benefit from tooling support.

Some patches are applied to a project's repository soon after being written, but other take more work. Consider, for example, support for stackable security modules, which has been through (at least) 38 revisions over many years. If and when this work lands in the Linux kernel mainline, it will bear little resemblance to what was initially posted years ago. Each revision will have undergone changes that will have rippled through much of the 39-part patch set. Git can support iteration on a series like that, but it can be a bit awkward, leading many developers to use other tools (such as Quilt) to manage in-progress work.

Leave a Comment