On 09/05/2011 21:04, Roman Leshchinskiy wrote:
On 09/05/2011, at 12:34, Manuel M T Chakravarty wrote:

Simon Marlow:

- 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).

I agree with this workflow.  I am not quite sure why you think it
is too complicated.  The rule is simple: rebase is a one-way street
(it changes patches and doesn't just move them), so you cannot just
merge back into the re-based branch.  SimonPJ asked for a recipe of
how to proceed with git.  I think you just provided that.

I'm rather lost now. Do we have to do this for the libs, too? Does
sync-all support rebase? It doesn't seem to. Could this be added?

Also, how do I find out if a branch has been rebased? And how do I
rebase two branches (or two trees) in sync? As usual, I'm too stupid
to understand the git docs. This all *is* quite complicated.

I am also too stupid to understand the git docs. We should start a club! What I know about git I've mostly discovered by experimentation, talking to people on IRC, and reading blog posts.

To answer your questions:

I haven't tried rebase with sync-all. I only use sync-all for simple tasks, e.g. to pull I do

  ./sync-all pull --ff-only

and anything that needs merging I do manually, with either rebase or merge as appropriate. I'm very tempted to make --ff-only the default.

A branch has been rebased if it has a different set of commits in it, so you can say something like 'git log other-branch..'.

I'm not sure exactly what it means to rebase two branches "in sync". I know that if you rebase a branch and the target of the rebase already has (some of) the patches that you are rebasing, then git will drop them during the rebase.

Cheers,
        Simon

_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to