Workflows, validate, and rebase
dave.terei at gmail.com
Thu Aug 25 21:19:15 CEST 2011
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
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.
On 25 August 2011 02:25, Simon Marlow <marlowsd at gmail.com> wrote:
> Hi folks,
> I've updated GHC's wiki page about workflows to include instructions about
> 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).
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
More information about the Cvs-ghc