Workflows, validate, and rebase

[Simon Marlow]

On 25/08/2011 20:19, David Terei wrote:
> So the rebase work flow advises the following steps:
>
> 1. fetch patches from ghc-working into ghc-validate: ./sync-all fetch working
> 2. merge from working: ./sync-all merge working
> 3. rebase onto master: ./sync-all pull --rebase
> 4. validate, push
>
> If I try this I get an error on the second step where ./sync-all
> complains it doesn't know the 'merge' command. Also, what are we
> gaining by doing both step 1 and step 2 when you could just do
> './sync-all pull working'? pull is equivalent to fetch + merge
> basically.
>
> Otherwise I like it. Its basically how I work but showed me a few
> ./sync-all tips I didn't know and is a nice easy read. I wonder if I'm
> the only one who still uses separate build trees though these days.
> Not sure if they are buying me much so might drop them myself.

Simon and I use separate build trees all the time, mainly because we 
want to keep our source trees on the backed-up NFS drive and build trees 
on fast local disk.  Also I can use the same source tree to make builds 
on different machines (I often have both a 32-bit and a 64-bit build of 
my working tree).

I know I could easily have separate source trees and make sure my local 
changes were backed up and shared using git (or just rsync), but it's 
just one less thing to worry about this way.

Cheers,
	Simon