Re: [PATCHv2 2/3] parse-remote: support default reflist in get_remote_merge_branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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???"

> 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
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]