Re: [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch
- From
- Santi Béjar <santi@agolina.net>
- Date
- Jun 7, 2009, 18:02 UTC
- Message-ID
- <adf1fd3d0906071102v9c15517v8e7b41a6638a52bb@mail.gmail.com>
- In-Reply-To
- <7vljo49e08.fsf@alter.siamese.dyndns.org>
2009/6/7 Junio C Hamano <gitster@pobox.com>:
Show 10 quoted lines
> 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)".
Show 13 quoted lines
> >> 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).
Show 32 quoted lines
> >> +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