On 24/05/11 18:31, Simon Peyton-Jones wrote:
| If we agree that the procedure that you outlined and the details that we
discussed in
| this thread are going into the direction of the policy that we would like to
adopt, I'd be
| happy to summarise the email thread on a wiki page.
I have not been following the details of this thread, but I'm willing to follow
instructions! Just to say, though, that for me it's absolutely essential to
have good wiki guidance saying explicitly how to follow the workflow. thanks!
(For now I will continue as before.)
I'm using rebase, but it does tend to be confusing - for instance, git
will constantly tell you that you have patches to push, when in fact
they are patches that you have already pushed (and rebased), but you
need to fetch and rebase to get rid of the duplicate patches in your
working tree.
So I'm not sure we can distill this as a set of instructions that
someone can just follow. You have to know how to inspect the state of
your repositories and make sense of them, and how to dig yourself out of
a hole (because this invariably happens, especially with rebase).
What do people think, should we be recommending rebase as our standard
workflow?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
