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. Cheers, David On 25 August 2011 02:25, Simon Marlow <[email protected]> wrote: > Hi folks, > > I've updated GHC's wiki page about workflows to include instructions about > rebase: > > http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Git > > I've been using `./sync-all pull --rebase` for a while now and it has been > working quite smoothly for me. It does help to give a more darcs-like > workflow where patches can be treated individually and > reordered/deleted/amended at will. > > I've also added some more blurb about how to set up the two-tree workflow > and the rationale for doing it this way. Please take a look and suggest > improvements (or just edit the page). > > Cheers, > Simon > > _______________________________________________ > Cvs-ghc mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/cvs-ghc > _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
