On 26/08/2011 00:37, Manuel M T Chakravarty wrote:
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.
I've added all these points to the wiki. Thanks!
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
