On 11/05/12 19:38, Konstantin Khomoutov wrote:
On Fri, 11 May 2012 18:35:03 +0300
Nikos Chantziaras<rea...@gmail.com>  wrote:

I don't want to push something that would require others to rebase.
But from the Pro Git book, in the "3.6 Rebasing" section, I had this
in mind:

    Do not rebase commits that you have pushed to a public repository.
    If you follow that guideline, you’ll be fine.

And indeed the commits I'm talking about have *not* been pushed to a
public repository; I just made those commits in master.  So my first
impression was that there would be no problem.  But it seems I didn't
understand what "rebase" really means.  I now understand that when
the book says "do not rebase pushed commits", it does not mean the
commits I just made in master and want to rebase them to exp.  It
means all the commits in exp.  Did I get that right now?

No, you got it right the first time, that is, your first impression
was correct. :-)

Now I'm confused.  See below.

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:
that is, it ends with commit C.

You fork another branch, "exp", off of it. Initially it looks exactly
the same:

Now you put commit X, and Y on exp, so it now looks this way:

In the meantime you committed M an N on master, so it looks like this:

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:
(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.

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.) I suppose this won't break things for the future when exp will finally be merged back into master?

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