Thread (2 messages) flat view 2 messages, 2 authors, 2016-12-01

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

From: Stefan Beller <hidden>
Date: 2016-12-01 18:24:55

Possibly related (same subject, not in this thread)

On Thu, Dec 1, 2016 at 9:59 AM, Junio C Hamano [off-list ref] wrote:
+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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help