On 12 May 2011 17:31, Tobias Hahn
<tobias.hahn@xxxxxxxxxxx> wrote:
Pull using rebase only rebases your local commits, so this cannot cause problems.
That's not true. If someone else clones your local repository, or you publish your branch on github, say, before doing your rebase, then they too will be affected.
Even rebasing shared feature branches is totally safe if you communicate this before pushing such a rebased branch ("Please don't push in the next ... minutes because I am going to rebase the branch.", git pull, rebase, build+test, git push -f, "All green."). IMHO, this should even be a best-practice as it helps to keep the history linear (but I know that there are other opinions).
Rebasing shared feature branch causes everyone else on that branch to rebase when they pull, right? So either your force everyone who's part of that share to rebase, or you request that they checkin, one committer does the rebase and then they all pull again using the new branch HEAD.
I am really sad that the git documentation makes such a big fuzz about rebase being a "dangerous" operation. IMHO, this causes a lot of FUD about a great feature and is not helpful at all.
I agree it's not bad if you know what you're doing. However fundamentally you are re-writing history, if that history is shared, both the person doing the rebase, and _every_ client that relies on rebased commits need to be aware of what's happen and where the new parents for their commit are... As a result rebasing on any branch which is non-local should be discouraged.
Cheers,
James
