What happened to having to recover from upstream rebase?
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?
Hi Phil,
Quoted 2 lines · Phil Susi
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).
Quoted 5 lines
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.
Quoted 10 lines · Johannes Schindelin
Hi Phil,
Quoted 2 lines · Phil Susi
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.
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/