2009/6/7 Junio C Hamano <gitster@xxxxxxxxx>: > Santi Béjar <santi@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html