Re: [Qemu-devel] Handling patch queues (was: [STATUS] static instrumentation)

[Andreas Färber]

Am 08.10.2010 um 18:53 schrieb Blue Swirl:

> On Thu, Oct 7, 2010 at 8:34 PM, Lluís <address@hidden> wrote:
> > Blue Swirl writes:
> >
> > > The patches there seem to be fixes or small changes to your other
> > > patches. This makes any review very difficult.
> >
> > Sorry, I'm really new to git, so I don't really know how to  
> > maintain and
> > "grow" an organized set of patches for review while I keep  
> > improving the
> > work.
>
> Some kind of patch queue or stack tool can help, I use StGit
> (integrates nicely with QGit) but there are others.
>
> The workflow should aim for a set of committable patches. This means
> that instead of patch sequence
> 1 - implement feature A
> 2 - fix for feature A
> 3 - implement feature B
> 4 - more fixes for feature A
> 5 - fixes for feature B
>
> etc, the patches should be perfected, like this:
> 1 - implement feature A
> 2 - implement feature B
>
> This can be achieved by working with the patch stack:
> 1 - implement feature A
> fix for feature A needed: fix, refresh 1
> 2 - implement feature B
> more fixes for feature A needed: pop 2, include fixes to 1
> fixes for feature B: push 2, fix and refresh 2

> This also makes keeping up with HEAD simpler (though conflicts need to
> be managed anyway):
> pop all patches
> git pull
> push patches one at a time, fix conflicts if needed.

git rebase -i origin/master  sometimes works for me.
Commits can then be selected to be reworked, followed by git rebase -- 
continue.
This usually works better than manual `git am` / `patch -p1` since you  
get a three-way merge.

Your last commit can be changed with git commit --amend. Especially  
handy is -s, which adds the forgotten SOB. ;)

I've used the pop-pull-push model with Mercurial's mq and find it  
really awful (uncomfortable), but that seems a matter of taste.

Instead I often use two Git branches per topic, one for (unordered)  
local work and one queue for upstream. On the latter I (cherry-)pick  
from the work branch, then rebase the work branch against the queue to  
slim it down. Updating to HEAD means one rebase against origin for the  
queue and one rebase -i against the queue. While rebasing becomes  
slightly more complicated, experimenting when you don't know in  
advance what you'll change next becomes easier and compilation times  
stay lower compared to frequent checkout of different file versions.

Working with one queue requires some caution, like backing up the  
branch before reworking (git branch / git format-patch).

HTH,
Andreas