On Wed, Nov 28, 2007 at 06:42:56PM -0500, Jon Smirl wrote: > I'm a patch developer. You need to change the patches continuously to > track feedback on the lkml type lists. You also have to rebase in > order to keep tracking head. Other people often work on the same > things and this triggers merges against the pending patches. Yeah, I use guilt for projects where I have a patch queue that takes a while to merge into the mainline, due to quality control or review guidelines that still need to be met. Basically the kernel has a different workflow than git, where each project or developer has a separate patch queue that is maintained inside git (possibly with guilt or stgit as helpers) or quilt, instead of a centrally managed pu branch. This is I suspect mainly a scaling issue; it's hard to keep a centrally maintained pu branch because anytime someone wants to make a change to one of their topic branches, they have to go through the central maintainer. The closest analogue to the pu branch is Andrew Morton's akpm, and he gets grumpy when there are merge conflicts between the various branches and patch queues that he pulls from in order to make the -mm tree for integration testing. > I'd just like for stgit to become a core part of git so that is can be > made more bullet proof. I'm losing my patch stack every couple of > weeks. It's normally a "user error" but it is way to easy to make > these user errors. I haven't tried using stgit in quite a while mainly because I was finding it too easy to lose my patch queue. It was happening to me *way* to often, and while it sounds like it's gotten better due to adding more sanity checks --- and when I tried it last, "stg repair" didn't exist --- it sounds like it is still possible for someone who typo's a command to get themselves into trouble. I'm sure it's not an issue for the stgit developers because they know which commands to avoid, but if something isn't 100% bulletproof --- I get nervous. So my solution to this problem is I use guilt. I *like* the fact that the primary storage mechanism is actual flat ASCII patch files, since as a result I've never lost a patch stack --- ASCII patch files are much more robust. My way of rebasing a set of patches is very simple; I just do "guilt pop -a; git merge master; guilt push -a" --- and if there are any conflicts, then I do a "guilt push -f", fix up the conflicts, follow it with a "guilt refresh", and then resume pushing the rest of my patches sing "guilt push -a". It just works; no muss, no fuss, no dirty dishes. Another thing this allows me to do is that it is possible to put the guilt patch stack itself under git control. This allows me to go backwards in time and see what the patch stack looked like n days or n weeks ago. A comment in the patch header indicates what version of the kernel the patch stack was meant against. For example for ext4 development the guilt patch stack is themselves stored using git on repo.or.cz, with multiple people having access to push updates to the patch queue. Before I start hacking the ext4, I'll do run the command "(cd .git/patches/ext4dev; git pull") to check for new updates in the ext4 patch queue, and if it has changed, I'll do a "guilt pop -a; guilt push -a" to refresh the working directory and ext4dev branch in my Linux git tree. When I'm done making changes, by using commands such as "guilt pop", "guilt refresh", "guilt pop", et. al., I'll commit changes in the .git/patches/ext4dev tree, and then push them back to repo.or.cz. We also have a system where an automated build/test server checks every few hours if the patch queue on repo.or.cz has changed, and if so, it pulls the patch queue, and then builds and tests the patch queue on a wide variety of hardware architectures (i386, x86_64, ia64, ppc64, s390, etc.) and sends an e-mail pack to the developers list telling us which test hardware platforms passed, and which platforms fail. Actually, we do two such tests --- one up to the "stable" point in the patch series, which represents the next set of patches we plan to push to Linus during the next merge window, and one for the entire patch queue (stable plus unstable patches that need more work). It works quite well for us --- and while there are some advanced feature that stgit has which guilt doesn't, the feeling of safety of knowing that the ASCII patch files won't get lost, and the ability to do things such as shared patch queue maintenance and ability to keep the patch queue under SCM are enough of a win that at least for my purposes guilt is the better choice. > stgit is what you need for this work flow. It lets me easily rebase or > edit specific patches. It also lets me easily maintain private debug > patches that I can apply as needed. As mentioned above, I use guilt for major patch queues. For smaller sets of patches, such as private debug patches, I just use a separate git branch for those, and keep them up-to-date by using "git rebase" and "git rebase -i". Then when I want to enable some debug patch, I'll just do a "git merge" in a scratch branch. - Ted - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
