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. 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. Mark this case as test_expect_failure to make people aware of this behavior. Signed-off-by: Santi Béjar <santi@xxxxxxxxxxx> --- Hi, I just wanted to make people aware of this behavior and then decide if this is the correct behavior, so document it, or try to find a better solution. Santi t/t5520-pull.sh | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh index c5a2e66..164a0eb 100755 --- a/t/t5520-pull.sh +++ b/t/t5520-pull.sh @@ -117,8 +117,23 @@ test_expect_success '--rebase with rebased default upstream' ' ' +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 + +' + 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) && -- 1.6.3.1.308.g426b5 -- 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