When we get an unqualified dest refspec like "foo", we try to guess its full ref path (like "refs/heads/foo") based on the source ref. Commit f8aae12 mapped local heads to remote heads, and local tags to remote tags. This commit maps local tracking branches under "refs/remotes" to remote branch heads, so git push origin origin/branch:renamed-branch pushes to refs/heads/renamed-branch. Signed-off-by: Jeff King <peff@xxxxxxxx> --- This came from a discussion on IRC. I don't see any reason not to do this; would people really expect it to push into refs/remotes/ on the other side (right now, it complains and dies)? A related issue (which exists even without this patch) is that doing this: master:remotes/incoming/master will create "refs/heads/remotes/incoming/master". Perhaps we should DWYM a little more and recognize "heads", "remotes", and "tags" as special. remote.c | 2 +- t/t5516-fetch-push.sh | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/remote.c b/remote.c index 73d33f2..1a7c81e 100644 --- a/remote.c +++ b/remote.c @@ -998,7 +998,7 @@ static char *guess_ref(const char *name, struct ref *peer) if (!r) return NULL; - if (!prefixcmp(r, "refs/heads/")) + if (!prefixcmp(r, "refs/heads/") || !prefixcmp(r, "refs/remotes/")) strbuf_addstr(&buf, "refs/heads/"); else if (!prefixcmp(r, "refs/tags/")) strbuf_addstr(&buf, "refs/tags/"); diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 6889a53..692c773 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -383,6 +383,15 @@ test_expect_success 'push tag with non-existant, incomplete dest' ' ' +test_expect_success 'push remote branch with non-existant, incomplete dest' ' + + mk_test && + git update-ref refs/remotes/foo/bar master && + git push testrepo foo/bar:branch && + check_push_result $the_commit heads/branch + +' + test_expect_success 'push sha1 with non-existant, incomplete dest' ' mk_test && -- 1.6.5.1.201.g7feba -- 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