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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
