Hi Phil, On 2015-05-11 21:50, Phil Susi wrote: > So it used to be that when upstream rebased, you'd get an error when > you tried to pull again Not necessarily. You would get this error *only* if there was a merge conflict between the revisions (one revision being your remote-tracking branch *before* the pull, the other revision being your remote-tracking branch *after* the fetch implied by the pull). > and have to fix things up with some git reset > or rebase hackery. Trying to demo this today I found that the pull > *worked*, using an automatic recursive merge. > > Am I crazy in thinking this used to error, and if not, when did it change? You are not crazy, but I believe it might be a misunderstanding how the rebased upstream and the pull interact. When an upstream branch is rebased after you merge it, you have essentially two disagreeing versions of upstream. My reading is that you mistook the error Git showed when trying to merge two disagreeing versions of upstream for an error produced by pull *directly* when it detects that upstream has been rebased. There is no such test in `git pull`, though. And when the upstream is rewritten in a way that does *not* cause merge conflicts [*1*], your workflow simply does not work. The easy way out is to use `git pull --rebase` which figures out from the previously fetched revisions of the upstream branch what commits were dropped/rewritten and does not attempt to merge them. Note: Your local commits on top of upstream are also rebased which possibly leads to conflicts using this method. Ciao, Johannes Footnote *1*: It is very easy to rewrite a branch in such a way: just amend the commit message and you end up with two disagreeing histories, where the *working directories* corresponding to the disagreeing revisions are identical and therefore merged in the most trivial manner. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html