Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <john@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]