Ramkumar Ramachandra <artag...@gmail.com> writes:

> Extend the test "migrate a remote from named file in $GIT_DIR/remotes"
> to test that multiple "Push:" and "Pull:" lines in the remotes-file
> works as expected.
> Signed-off-by: Ramkumar Ramachandra <artag...@gmail.com>
> ---
>  t/t5505-remote.sh | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
> index 229a89c..6a622fc 100755
> --- a/t/t5505-remote.sh
> +++ b/t/t5505-remote.sh
> @@ -735,7 +735,9 @@ test_expect_success 'rename a remote with name prefix of 
> other remote' '
>  cat >remotes_origin <<-EOF
>  URL: quux
>  Push: refs/heads/master:refs/heads/upstream
> +Push: refs/heads/master:refs/heads/upstream2
>  Pull: refs/heads/master:refs/heads/origin
> +Pull: refs/heads/master:refs/heads/origin2
>  EOF

I do not think we ever designed this to get 'master' pushed to
update two separate destination branches or their 'master' to update
our two separate tracking branches.

If you want to make things more realistic like you did in 08/14, I
do not see a point to change the tests that is already done for a
useful and realistic case by making it deliberately less realistic.

The same comment applies to the bogus quux URL from the patch 04/14.

I'll reject 04/14 and tweak this patch to use 'next' for the new ref
mappings, not duplicated 'master'.

Patches 07/14, 12/14, 13/14, and 14/14 are bad idea (these will not
be queued on tonight's pushout of 'pu'; neither 04/14 will be).  We
may not be encouraging, but that is very different from deprecating
the original mechanisms.  The tests that depend on them to work
should be kept.  Otherwise, we will never know when we break them
like we did at df93e33c accidenally.

If we want to have tests that exercise the equivalents spelled with
the modern in-config mechanism, they should be added as new tests,
not by replacing the existing ones.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to