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- forward); 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 well. 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 OK. -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.