PatchManagement
OBSOLETE CONTENT
This wiki has been archived and the content is no longer updated. Please visit git-scm.com/doc for up-to-date documentation.
Scope of this page
I define "patch management" as a way of dealing with modifications to source code, which emphasizes the importance of changes themselves.
Tools for patch management existed before GIT, most notably Quilt and Darcs, and patch management tools integrating with other versionning systems exist. We have already seen a number of patch management tools appear on top of GIT, and they all bring their set of interesting ideas.
This page is meant to collect those ideas found in all existing patch-management tools, as well as ideas from users who need better patch management.
Existing tools for patch management
Standalone
Quilt is probably the most used patch-management tool that not depending on a particular VCS. It is the inspiration of most patch-management tools mentionned in this page.
Darcs is a patch-centered VCS.
Layers above GIT
StGIT is at this date the most advanced patch-management tool built on GIT.
Pg is a prototype tool whose latest version (0.1.7) experiments with the tracking of patch history.
guilt (formerly gq) also emphasizes on the tracking of patch history, but in another way.
Layers above other VCS
Mq extension to Mercurial.
Typical workflows needing patch management
- maintainance of a series of local patches against an upstream branch
- preparing a series of patches for acceptance into an upstream branch
- development/maintainance of several such related branches (eg. linux BSPs forked off different arch-specific trees), making sure in each branch that all relevant changes in other branches were integrated, and uptodate
Ideas and needs for future developments
Organizing patches
What's available in current tools
Many patch-management tools, as inspired by Quilt, are centered on the idea that patches must be organized as a series (or stack) of patches. Others, like Darcs, are more flexible: instead of forcing upon the user a sometimes-arbitrary order of patches, some (many) patches can be considered as independant from one another.
More precisely:
- StGIT 0.11 stores a patch as a GIT commit whose single parent is the patch below it in the stack
- Pg 0.1.7 stores a patch quite similarly to StGit, but also recording as parent the commit representing the previous version of the patch.
Other ideas
One idea, raised by Shawn Pearce (author of Pg) would be to manage independant patches in different GIT branches (topic branches).
Tracking patch history
What's available in current tools
The approach in pg 0.1.7 of using merge commits, while allowing to track the full history of each patch, quickly creates a heavy history, which becomes unusable after commuting patches a couple of times. Furthermore, that way of doing things turns changes from lower patches indeed part of higher patches (for merging purposes, etc.) - that's what a merge commit means.
StGit (since 0.11) tracks the history of each patch in a special "log branch". It is more lightweight than the pg approach, since they do not interfere with the stack itself, but are still of limited interest, since they too get poluted by changes in patches down the stack.
What's still missing
Todo
