Re: "git rebase" behavior change in 2.26.0

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

 



On Wed, Mar 25, 2020 at 8:37 PM Elijah Newren <newren@xxxxxxxxx> wrote:
> Now, when I try to duplicate, just for fun I added some 'die("You ran
> a merge!")' and 'die("You ran a rebase!")' lines early in
> builtin/{merge,rebase}.c, just so I could verify what was run.  Then I
> tried to use a command line similar to yours:
>
> $ git -c rebase.backend=merge -c pull.rebase=false -c
> branch.master.rebase=true pull
> remote: Enumerating objects: 5, done.
> remote: Counting objects: 100% (5/5), done.
> remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
> Unpacking objects: 100% (3/3), 250 bytes | 250.00 KiB/s, done.
> From /home/newren/floss/git/testing/pull-rebase-orig-head/repo
>    c911eef..2ccdb90  master     -> origin/master
> fatal: You ran a merge!
> fatal: You ran a rebase!
>
>
> Say, WAT?!?  This attempted to run both a merge and a rebase?  That
> appears to be yet another bug.

>From git-pull.c:

    ...
        if (is_descendant_of(merge_head, list)) {
            /* we can fast-forward this without invoking rebase */
            opt_ff = "--ff-only";
            ret = run_merge();
        }
    }
    ret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);

Perhaps that comment should read:

   /* we can fast-forward this using merge and avoid rebase...but then
run rebase afterward anyway! */

Whoops.  Perhaps fixing this is a good micro-project candidate?  Too small?



[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]

  Powered by Linux