On 09/05/2011 05:48, Manuel M T Chakravarty wrote:
Simon Peyton-Jones:
It's a long message and I don't understand it.
Suppose we have * A branch * Shared between several people *
Long-lived (weeks not day) how should we manage it?
It *must* be possible to merge fixes from the master into the
branch. Doing so, and then validating, is essential because (as we
have painfully learned) it simply isn't possible to anticipate all
interactions. Moreover, quite often the master is changing (say)
the type checker and so is the branch; Linus seems to regard this
as exceptional, but to me it seems the norm.
Linus does say that if there is a real dependence of your new code on
changes in the master, you need to get those changes. He just
discourages pulling changes in from the master out of habit.
If someone would like to write a duffers guide describing how to do
that, I'm happy to follow it. But the only way I understand is to
merge master onto the branch regularly, and finally merge the
branch onto the master. I don't see the disadvantage of this
approach. Yet.
In my limited understanding of git, you should use rebase to add your
changes to the master, where possible. Otherwise, you end up with a
muddled history and lots of spurious merge commits. (I have never
used git on a large project, so I'm really just regurgitating the
advice of others.)
We can of course continue to use our old darcs-ish workflow with git
and see what happens. In all likelihood, we'll find the same
problems others found. I doubt Linus and other longterm git users
adopted their more involved workflows without a reason.
Some of us are using rebase to avoid merge commits where possible, but
it is quite easy to get into a mess so I hesitate to suggest rebase as
our recommended workflow. Ordinary merging works fine modulo the noisy
merge commits, so I'm happy for people to just do 'git pull' unless
they're comfortable with rebase. Some projects require their developers
to be git experts; I don't think that's practical for us. Maybe that
will change over time, I don't know.
One reason that rebase isn't straightforward for us is the two-tree
validate workflow. We've discussed this quite a bit on IRC and I don't
think there's a good solution. Basically what happens is this:
- you develop in your working tree and commit patches there. At
this point it's completely safe to rebase - the patches are only
in one place.
- you pull the patches into the validate tree (you just rebased in
working, so no conflicts or merges required here)
- run validate (takes ~30 mins)
- try to push - oops, someone else already pushed something
- now we have a choice: merge or rebase.
- merge: we get a merge commit, but later pulling into the working
tree works fine.
- rebase: no merge commit, but we have to remember to rebase the
working tree again, otherwise the next pull will be a conflict.
I've been doing the rebase scheme and it generally works ok: git notices
when it is rebasing a patch that already exists, and discards it. But,
it's complicated enough that I'm wary of recommending this as our
standard workflow. (also, needing rebase feels wrong somehow, but
that's more of a philosophical point).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
