From: Junio C Hamano <gitster@pobox.com>
To: "Santi Béjar" <santi@agolina.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch
Date: Sun, 07 Jun 2009 09:59:03 -0700 [thread overview]
Message-ID: <7vljo49e08.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: 1244367862-6306-2-git-send-email-santi@agolina.net
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
next prev parent reply other threads:[~2009-06-07 16:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2009-06-07 18:02 ` Santi Béjar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vljo49e08.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=santi@agolina.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).