On Sun, Sep 25, 2011 at 08:38:55PM -0700, Prasad wrote:
> I work in a company where we maintain Linux kernel and make few
> changes on top of it. I have a public Linux kernel (by public I mean
> internal to company however, few employees have cloned from the
> repository). The version of Linux kernel is 3.0 and with few changes
> on master branch.
> Now I want to pull the latest kernel 3.1-rc7 and apply our patches on
> top it. We are very much sure that our existing changes would not
> cause any conflict. I was thinking about rebasing the code, however
> the book "Pro Git" says "Do not rebase commits that you have pushed to
> a public repository.".
> Now I am confused. Can someone help?
Well, the book then goes to great lengths to back this statement up.
The git-rebase manual page also discusses this possible pitfall in
detail so check it out.
In short, when you rebase a series of commits the resulting line of
history will contain the same series of commits at its tip but while
this series will be identical to the original by its *contents* each
commit will have different SHA-1 hash.
Hence if you rebase a branch and then push it to a public repo forcibly
replacing the original branch (note this important fact!) you kind of
change the world view for everyone who has work based on this branch.
But in fact there's no need to be too afraid of this: if everyone on the
team is informed about the prospective rebasing before it's done then
after the rebasing and pushing everyone just fetches the rebased branch
and rebases whatever work they had in their repository based on that
Having said that, I'm not sure you do really need rebasing in this case.
Merging is not bad and basically you'll end up with the same contents of
the source tree just the history will look differently.
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