On May 13, 8:14 pm, Rick DeNatale <rick.denat...@gmail.com> wrote:

> I've accepted the warning that you shouldn't rebase a branch unless it
> has never been pushed to a shared repository since it can wreak havoc
> on others who have pulled the branch.
> Yehuda Katz just wrote about his git 
> workflowhttp://yehudakatz.com/2010/05/13/common-git-workflows
> He advocates using git pull --rebase, rather than letting git pull use
> the default of merging instead of rebasing.
> Is this good advice?

I agree with Peter Shenkin.

And I interpret the warning in the git-pull manual -- "This is a
potentially _dangerous_ mode of operation. It rewrites history, which
does not bode well when you published that history already." -- as a
precaution for the case when the changes you're rebasing during the
pull are also contained in some other (local) branch which is already
pushed or will be pushed later.
To clarify: suppose we have this setting:
1) You have identical commits on both "master" and "origin/master";
2) Then you fork a branch "foo" off "master" and add 10 commits on top
of it;
3) Then you merge "foo" back to "master" (which would result in fast-
5) Then you do `git pull --rebase` on "master".
This operation will remove these 10 commits off your "master" branch,
promote it to the state of "origin/master" and then reapply these
removed commits.
Now you push your updated master and then push that "foo" branch as
The problem is that these 10 commits which are supposed to be shared
between "master" and "foo" are now different.

So, I think if this implication is understood, `git pull --rebase` is

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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to