Re: [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch

["Santi Béjar" <santi@agolina.net>]

2009/6/7 Junio C Hamano <gitster@pobox.com>:
> Santi Béjar <santi@agolina.net> writes:
>
>> Expand get_remote_merge_branch to compute the tracking branch to merge
>> when called without arguments (or only the remote name). This allows
>> "git pull --rebase" without arguments (default upstream branch) to
>> work with a rebased upstream.
>
> The last sentence leaves readers wondering...  "Ok, with this patch, X
> without Y now works.  What about X _with_ Y?  Is it left unfixed?  Was it
> already working before this patch?  What is going on???"

No changes in the "with Y" case, so working.

Maybe add the sentence "( with explicit arguments it already worked)".

>
>> Also add a test to check for this case and another one (failing) to
>> test rebasing two branches on top of a rebased upstream using just
>> 'git pull --rebase'.
>
> "test doing X using just Y" _sounds as if_ you are implying
>
>        Doing X using Z (that is more cumbersome to type than Y) works but
>        doing X using Y (that ought to be the equivalent to Z) does not.
>        Let's expose this inconsistent breakage.
>
> without saying what Z is, and/or why Y is preferred.  So if that is what
> is going on, please spell these out.

If you have two branches tracking an upstream that is rebased,
currently you have to do:

git checkout branch1
git pull --rebase remote branch
git checkout branch2
git pull --rebase remote branch

The second rebase works because the first "git pull --rebase" does not
store in the local tracking branch the new value, so the second rebase
detects that it is rebased.

I think one should be able to do the same without the explicit
arguments to "git pull --rebase", but without arguments it stores the
new state of the remote branch so the second "git pull --rebase" does
not work.

I just wanted to single out that it does not currently works.

I see two solutions for this: 1) declare that it is not going to work
and to do it you have to do the explicit invocation or 2) examine the
reflog of the remote tracking branch.

> If that is not the case please drop "just"; it is confusing.

I'll add some of this explanation to the commit message, and keep the
"just" (they should be equivalent, but are not).

>
>> +test_expect_success '--rebase with rebased default upstream' '
>> +
>> +     git update-ref refs/remotes/me/copy copy-orig &&
>> +     git checkout --track -b to-rebase2 me/copy &&
>> +     git reset --hard to-rebase-orig &&
>> +     git pull --rebase &&
>> +     test "conflicting modification" = "$(cat file)" &&
>> +     test file = $(cat file2)
>> +
>> +'
>> +
>> +test_expect_failure '--rebase with rebased upstream and two branches' '
>> +
>> +     git update-ref refs/remotes/me/copy copy-orig &&
>> +     git reset --hard to-rebase-orig &&
>> +     git checkout --track -b to-rebase3 me/copy &&
>> +     git reset --hard to-rebase-orig &&
>> +     git pull --rebase &&
>> +     test "conflicting modification" = "$(cat file)" &&
>> +     test file = $(cat file2) &&
>> +     git checkout to-rebase2 &&
>> +     git pull --rebase me copy
>> +
>> +'
>> +
>>  test_expect_success 'pull --rebase dies early with dirty working directory' '
>>
>> +     git rebase --abort &&
>> +     git checkout to-rebase &&
>
> Hmm, saying "--abort" when rebase is not in progress

The rebase is in progress (the last test failed)

> (i.e. after your next
> patch fixes the above "expect_failure" to pass) does not error out?  It is
> not very nice...

My next patch does not fix the expect_failure, I only wanted to make
this behavior explicit. But if at the end this is the prefered
behavior (fail rebasing two branches with a rebased upstream) I'll
drop this test.

Santi