On Fri, 11 May 2012 18:35:03 +0300
Nikos Chantziaras <rea...@gmail.com> wrote:
> > The consequence is that if you push a branch containing commits
> > ...->A->B-C
> > (with C being the tip commit) to a public repo, then rebase these
> > three commits to produce
> > ...->A'->B'->C'
> > and push it again (this would require a forced push), everyone who
> > happened to fetch the original state of your branch and base their
> > work on it (on the commit C, that is) will have pain in the neck
> > when their next fetch from your repo will suddenly replace a series
> > of tip commits on that branch. Everyone will be required to rebase
> > their work in turn, to follow your rebase.
> 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. :-)
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
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.)
Here, we changed the base of the series X->Y to be N instead of C.
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.
> Btw, in case you're also using Mercurial, my workflow there is:
> * make a commit in master
> * "hg export" that commit
> * switch to the exp branch
> * "hg import" the commit
> This would be "merge" in Git rather than "rebase", right?
Uh, I don't quite follow.
Merge commits in Git happen only when you run `git merge` or something
which ultimately calls `git merge` (`git pull` might do this for
>From what I read in `hg import` manual, the closest thing in Git would
be `git format-patch` + `git am`. Also `git cherry-pick` is able to
"pick" arbitrary commit (or a series of them) and apply it/them to the
Rebasing in Git is used for a bit different need as I tried to
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 email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at