Git, merging and rebasing

[Simon Marlow]

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