I'm using git 2.2.1 on Mac OS X Yosemite. I just tried the git rebase with "--fork-point" added, and it works properly:
$ git rebase upstream/our-branch-name --fork-point First, rewinding head to replay your work on top of it... Applying: B-07241 While discussing with someone else, he mentioned "poking about a bit more, git rebase began defaulting to --fork-point in git 1.9, so one might expect it to be there in that version" - but we figured it might be related to https://github.com/git/git/commit/1e0dacdbdb751caa5936b6d1510f5e8db4d1ed5f. I upgraded my version of git, but it wasn't fixed. I assume he was incorrect in that git rebase uses --fork-point by default? On Tue, Mar 3, 2015 at 1:09 PM, John Keeping <j...@keeping.me.uk> wrote: > On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote: >> I'm seeing unexpected behavior between "git pull --rebase" and "git >> rebase" commands, which are supposed to be (and always described as) >> synonymous: >> >> git pull --rebase upstream our-branch-name >> >> and >> >> git fetch upstream >> git rebase upstream/our-branch-name >> >> We have a situation where the upstream/our-branch-name was rebased, to >> incorporate changes from master. Somehow, the person who did the >> rebase discarded a merge commit: >> >> 634b622 Sue Merge pull request #254 from bob/B-07290 >> bc76e5b Bob [B-07290] Order Parts Ship To/Comments >> >> became: >> >> c1452be Sue [B-07290] Order Parts Ship To/Comments >> >> >> A developer who had a local branch tried to rebase their work (a >> single commit on top of that feature branch). >> >> At the moment, his now-out-of-date branch looks like this: >> >> 92b2194 Rick B-07241 >> 634b622 Sue Merge pull request #254 from dboyle/B-07290 >> bc76e5b Bob [B-07290] Order Parts Ship To/Comments >> >> I've done some debugging, and the above "git pull" command generates >> the following and sends it to eval(): >> >> git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d >> 634b622870a1016e717067281c7739b1fe08e08d >> >> This process works perfectly. The old commits are discarded and his >> branch now correctly reflects upstream/our-branch-name, with his >> single new commit at the top. >> >> >> However, if he runs the "git rebase" command above, several of the >> commits that have changed hashes (they've also changed patch id >> slightly, because during the rebase someone fixed a merge conflict) >> are treated as new work, and git tries to re-apply them and we get >> tons of merge conflicts. >> >> The git rebase command above is trying to rebase onto: >> >> revisions = >> c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 >> >> >> These two features should work the same, yet one is choosing a >> different commit hash than the other. >> >> If this is not a bug, I can't find anyone who can explain what's >> happening. I'm using git 2.2.1 on mac, but other people on our team >> have a variety of older versions and we're all seeing the same result. > > What version of Git are you using? > > Does it work if you add the `--fork-point` argument to git-rebase? If > so, does it do the same if you just do "git rebase" with no arguments > (see the documentation of `--fork-point` in git-rebase(1) for details of > this)? -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
