Workflows, validate, and rebase

[Manuel M T Chakravarty]

Simon Marlow:
> 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).

Great! 

Concerning the rationale, at least with darcs, we often had the case that people forgot to add some files in the working tree and when they used the same tree for working and validate, validate went through, but still left us with a broken tree.  For me that was always a strong reason to use the two-tree set up.  It may be less of a concern with Git, which more actively complains about files that haven't been added.  I am not sure, is it still worthwhile adding something like that to the text?  Are there other scenarios in which validate succeeds with one tree, but would show a breakage with two trees?

As for the workflow, I do actually rebase in the working tree, and then, pull the rebased patches into the validate tree.  One reason I prefer that flow is that, if validate fails, it makes it easier to fix the problems in the working tree without any need for reset or similar.  (It also means I get conflicts, if there are any during rebase, in my working tree, which I strongly prefer.)

Only if somebody else pushed a patch, while I was validating and my validate was successful, I do a second rebase in the validate tree.

Manuel