# What happened to having to recover from upstream rebase? 3 messages from 2015-05-11 to 2015-05-13. Participants: Phil Susi, Johannes Schindelin, Matthieu Moy. Thread: https://gitlist.dev/t/39300 ## Phil Susi, 2015-05-11 19:50 Subject: What happened to having to recover from upstream rebase? Message-ID: <555107F7.1040906@gmail.com> URL: https://gitlist.dev/e/555107F7.1040906%40gmail.com ``` So it used to be that when upstream rebased, you'd get an error when you tried to pull again 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? ``` ## Johannes Schindelin, 2015-05-13 09:37 Subject: Re: What happened to having to recover from upstream rebase? Message-ID: URL: https://gitlist.dev/e/b1686e402e9459e58acc7700a12f377d%40www.dscho.org In-Reply-To: <555107F7.1040906@gmail.com> ``` 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. ``` ## Matthieu Moy, 2015-05-13 09:44 Subject: Re: What happened to having to recover from upstream rebase? Message-ID: URL: https://gitlist.dev/e/vpq617wzuah.fsf%40anie.imag.fr In-Reply-To: ``` Johannes Schindelin writes: > 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). However, you would get an error if you try to *push* (non-fast forward, because the remote has new commits which are different from yours even though they represent similar changes). And one solution to this error would be some rebase or reset magic. So, Phil, that may be the error you remember. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ```