Git, merging and rebasing

[Roman Leshchinskiy]

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.

Roman