On Fri, May 11, 2012 at 09:50:18PM +0300, Nikos Chantziaras wrote:

> >The idea with rebasing is that you can rebase any series of commits
> >(ending with the branch's tip commit) on top of technically any other
> >series of commit.  You do not have to rebase the whole branch.  "To
> >rebase a branch" is just a popular way to spell it, but it's not
> >technically perfect: you usually rebase just some series of commits
> >near the tip of a branch, and usually this series starts right after
> >the commit which is a common ancestor of both branches.  Of course,
> >there's very little sense to rebase a series of commits onto something
> >completely irrelevant and so the typical case for rebasing is like this:
> >
> >You have a branch, say, "master", which looks like this:
> >...->A->B->C
> >that is, it ends with commit C.
> >
> >You fork another branch, "exp", off of it. Initially it looks exactly
> >the same:
> >...->A->B->C
> >
> >Now you put commit X, and Y on exp, so it now looks this way:
> >...->A->B->C->X->Y
> >
> >In the meantime you committed M an N on master, so it looks like this:
> >...->A->B->C->M->N
> >
> >And now you want to pretend that X and Y on exp were made relative to
> >the *current* tip of master, which is now N (as opposed to it being C
> >at the time exp was forked off of it).
> >Observe that C is what's called the common ancestor for both the
> >involved branches here.
> >So you rebase the series X->Y in exp onto master, and exp starts to
> >look like this:
> >...->A->B->C->M->N->X'->Y'
> >(And the common ancestor is now N.)
> This is why I'm confused now.  If I understood it right the first
> time, I am rebasing M and N.  But here you say that X and Y are
> getting rebased.
I fear this might be a point-of-view issue.
I tried to explain what happens when you rebase some commits present on
"exp" onto the new tip of "master".  If you want to rebase some commits
on "master" onto the new tip of "exp", just exchange branch names in the
above discussion.  Name them "foo" and "bar" after all.

Let's try to recap: rebasing, in essense, is changing the base (hence
why "rebasing") of a series of commits (which end in the branch's tip).
If you're "rebasing foo onto bar", you're changing the base of some
commits in foo to be the bar's tip, so that foo looks like bar with that
rebased series of commits applied onto its tip.

Technically, there are other cases for rebasing, but this one is the
simplest and most used (maybe with exception to squashing and fixups).

> >The problem with rebasing and a public repo would only appear here if
> >you would have managed to push exp into that public repo after
> >committing X or Y.  If the exp branch ends in C in the remote repo,
> >it's fine to rebase X->Y in your local version of exp.
> exp contains pushed commits and has diverged from master.  master
> also contains commits made after exp was branched.  Most of the new
> commits in master need to also be applied to exp, but not all, since
> some of them touch code that has been replaced with a different
> implementation in exp.  (So in this case, exp doesn't add new
> features; it rewrites part of master using a better implementation.)
> It seems I need to use cherry-pick (which looks like the equivalent
> of hg export/import.) 
Yes, to me it looks like a case for cherry-picking.

> I suppose this won't break things for the future when exp will finally
> be merged back into master?
It's hard to tell precisely.
Git is rather good at merging, but cherry-picked commits bear no meta
information about what they result from (contrary to merge commits) so
when merging "exp" back to "master", it will be up to textual merging
machinery to detect equivalent text changes in both lines of history.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to