* [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch
@ 2009-06-07 9:44 Santi Béjar
2009-06-07 16:59 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Santi Béjar @ 2009-06-07 9:44 UTC (permalink / raw)
To: git
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.
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'.
Signed-off-by: Santi Béjar <santi@agolina.net>
---
Changes from v1:
- Hopefully provide a more useful and correct commit message
git-parse-remote.sh | 8 +++++++-
t/t5520-pull.sh | 29 +++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 8b3ba72..5df5689 100644
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -232,7 +232,13 @@ get_remote_refs_for_fetch () {
get_remote_merge_branch () {
case "$#" in
0|1)
- die "internal error: get-remote-merge-branch." ;;
+ origin="$1"
+ default=$(get_default_remote)
+ test -z "$origin" && origin=$default
+ curr_branch=$(git symbolic-ref -q HEAD)
+ [ "$origin" = "$default" ] &&
+ echo $(git for-each-ref --format='%(upstream)' $curr_branch)
+ ;;
*)
repo=$1
shift
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 725771f..359a3e2 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -92,20 +92,49 @@ test_expect_success '--rebase with rebased upstream' '
git remote add -f me . &&
git checkout copy &&
+ git tag copy-orig &&
git reset --hard HEAD^ &&
echo conflicting modification > file &&
git commit -m conflict file &&
git checkout to-rebase &&
echo file > file2 &&
git commit -m to-rebase file2 &&
+ git tag to-rebase-orig &&
git pull --rebase me copy &&
test "conflicting modification" = "$(cat file)" &&
test file = $(cat file2)
'
+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 &&
git update-ref refs/remotes/me/copy copy^ &&
COPY=$(git rev-parse --verify me/copy) &&
git rebase --onto $COPY copy &&
--
1.6.3.1.308.g426b5
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch
2009-06-07 9:44 [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch Santi Béjar
@ 2009-06-07 16:59 ` Junio C Hamano
2009-06-07 18:02 ` Santi Béjar
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2009-06-07 16:59 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
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???"
> 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 that is not the case please drop "just"; it is confusing.
> +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 (i.e. after your next
patch fixes the above "expect_failure" to pass) does not error out? It is
not very nice...
> git update-ref refs/remotes/me/copy copy^ &&
> COPY=$(git rev-parse --verify me/copy) &&
> git rebase --onto $COPY copy &&
> --
> 1.6.3.1.308.g426b5
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch
2009-06-07 16:59 ` Junio C Hamano
@ 2009-06-07 18:02 ` Santi Béjar
0 siblings, 0 replies; 3+ messages in thread
From: Santi Béjar @ 2009-06-07 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-06-07 18:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-07 9:44 [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch Santi Béjar
2009-06-07 16:59 ` Junio C Hamano
2009-06-07 18:02 ` Santi Béjar
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).