On Tue, Jul 20, 2010 at 7:52 PM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message AANLkTil1Czc80PISUCnoxQK0lVhfTuDbwVNnsoZ9Cc-_@mail.gmail.com you wrote:
I would also recommend looking at 'Stacked Git' (stgit) - It is basically a wrapper around it which allows you to manage a set of patches and move back and forth between them, merge, re-order etc.
It makes life a lot easier when you make a mess of things :)
What exactly can stgit do that cannot be done with a number of branches and "git rebase -i" ? [Sorry for the stupid question, but I haven't used stgit yet...]
Probably nothing, but it is more straightforward
Lets say you are working on a branch, say 'Testing'
git checkout testing stg new (opens an editor, allows you to write up a commit message) edit stg refresh stg new / edit / stg refresh (as many as you like)
Now you will have a bunch of commits, but maybe they are in the wrong order
eg
[arch commit 1] [common commit 1] [arch commit 2] [board commin 1] [arch commit 3]
etc, etc
you can then use stg pop/push/merge to re-arrange and merge commits together to get them in a more logical arrangement before submitting
Sometimes when I'm in the middle of a very long development session I tend to end up with one 'big patch' which has multiple logical change units. In this case, you can pop the 'big patch', insert a new smaller patch implementing some of the 'big patch' then when you push the 'big patch', all the duplicate changes are stripped. So you can basically whittle down a big, complex commit into multiple smaller commits very easily.
I'm sure you'll argue that this is poor development management, but I find myself more efficient if a 'get in the zone' and then go back and break things up. It also serves as a really good self imposed code review
It also has some inter-branch managment commands I have never used
Regards,
Graeme