Re: Re* git pull --rebase should use fast forward merge if possible

From: Stefan Beller <sbeller@google.com>
Date: Dec 1, 2016, 18:24 UTC
Message-ID: <CAGZ79kZSEan5uXCUn4iVCWEc9zohMSr+UDyHDyQUHz84H=tR8w@mail.gmail.com>
In-Reply-To: <xmqqa8cfbkeq.fsf_-_@gitster.mtv.corp.google.com>

On Thu, Dec 1, 2016 at 9:59 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

> +test_expect_success '--rebase fast forward' '
> +       git reset --hard before-rebase &&
> +       git checkout -b ff &&
> +       echo another modification >file &&
> +       git commit -m third file &&
> +
> +       git checkout to-rebase &&
> +       git pull --rebase . ff &&
> +       test "$(git rev-parse HEAD)" = "$(git rev-parse ff)" &&
> +
> +       # The above only validates the result.  Did we actually bypass rebase?

Good catch for the test, but I think we can make the sed regexp simpler, as we can leave out the second "[0-9a-f]"? (git reflog |sed "s/^[0-9a-f]*/OBJID/" works here)

The implication of that we'd also match if there is no object id at all at the beginning, which sounds fine.

I shortly debated the idea to just cut off anything before the first space and then expect "HEAD@{0}: pull --rebase . ff: Fast-forward" only, but why cut off what we produce in the first place?

    git reflog --format="%s" -1 >actual &&
    echo "pull --rebase . ff: Fast-forward" >expect &&
    test_cmp expect actual

maybe?