Git, merging and rebasing

[Manuel M T Chakravarty]

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

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.

(Re the philosophical point, I agree, it is disturbing to functional programmers as rebase mutates patches.  Darcs idea of commuting patches appears more elegant, but git has the more mature implementation and all the infrastructure.)

Manuel