Git, merging and rebasing
marlowsd at gmail.com
Tue May 10 11:16:55 CEST 2011
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
>> 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.
More information about the Cvs-ghc