Re: Rollback of git commands

[Theodore Tso <tytso@mit.edu>]

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