Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 <artagnon@xxxxxxxxx> > --- > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html