Am 08.10.2010 um 18:53 schrieb Blue Swirl:
On Thu, Oct 7, 2010 at 8:34 PM, Lluís <xscr...@gmx.net> 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