This adds a test case for unambigous local match but multiple remote matches. To me, it is unexpected that a ref that is perfectly defined on the local side fails with 'matches more than one'. The following rule could solve this: A ref shall first be unambigously resolved on the local side, and its full name should be used for matching on the remote side. For example 'frotz' resolves locally to 'heads/refs/frotz'. Therefore pretend the user had typed 'heads/refs/frotz'. But maybe there is some hidden secret about the current rules that I do not see. Signed-off-by: Steffen Prohaska <prohaska@xxxxxx> --- t/t5516-fetch-push.sh | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index ca46aaf..f249216 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -244,4 +244,12 @@ test_expect_success 'push with colon-less refspec (4)' ' ' +test_expect_success 'push with colon-less refspec (locally unambigous)' ' + + mk_test heads/frotz heads/t/frotz && + git branch -f frotz master && + git push testrepo frotz + +' + test_done -- 1.5.3.4.219.gd0b2 - 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
