From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH v2 05/12] refs DWIMmery: use the same rule for both "git fetch" and others
Date: Mon, 7 Nov 2011 19:00:38 -0800 [thread overview]
Message-ID: <1320721245-13223-6-git-send-email-gitster@pobox.com> (raw)
In-Reply-To: <1320721245-13223-1-git-send-email-gitster@pobox.com>
"git log frotz" can DWIM to "refs/remotes/frotz/HEAD", but in the remote
access context, "git fetch frotz" to fetch what the other side happened to
have fetched from what it calls 'frotz' (which may not have any relation
to what we consider is 'frotz') the last time would not make much sense,
so the fetch rules table did not include "refs/remotes/%.*s/HEAD".
When the user really wants to, "git fetch $there remotes/frotz/HEAD" would
let her do so anyway, so this is not about safety or security; it merely
is about confusion avoidance and discouraging meaningless usage.
Specifically, it is _not_ about ambiguity avoidance. A name that would
become ambiguous if we use the same rules table for both fetch and local
rev-parse would be ambiguous locally at the remote side.
So for the same reason as we added rule to allow "git fetch $there v1.0"
instead of "git fetch $there tags/v1.0" in the previous commit, here is a
bit longer rope for the users, which incidentally simplifies our code.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache.h | 2 +-
refs.c | 8 --------
t/t5510-fetch.sh | 5 ++---
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/cache.h b/cache.h
index be07ec7..26322dd 100644
--- a/cache.h
+++ b/cache.h
@@ -873,7 +873,7 @@ extern int get_sha1_mb(const char *str, unsigned char *sha1);
extern int refname_match(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
-extern const char *ref_fetch_rules[];
+#define ref_fetch_rules ref_rev_parse_rules
extern int create_symref(const char *ref, const char *refs_heads_master, const char *logmsg);
extern int validate_headref(const char *ref);
diff --git a/refs.c b/refs.c
index ff20eeb..026c7ea 100644
--- a/refs.c
+++ b/refs.c
@@ -995,14 +995,6 @@ const char *ref_rev_parse_rules[] = {
NULL
};
-const char *ref_fetch_rules[] = {
- "%.*s",
- "refs/%.*s",
- "refs/tags/%.*s",
- "refs/heads/%.*s",
- NULL
-};
-
int refname_match(const char *abbrev_name, const char *full_name, const char **rules)
{
const char **p;
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 7e433b1..251d138 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -116,7 +116,7 @@ test_expect_success 'fetch must not resolve short tag name' '
'
-test_expect_success 'fetch must not resolve short remote name' '
+test_expect_success 'fetch can now resolve short remote name' '
cd "$D" &&
git update-ref refs/remotes/six/HEAD HEAD &&
@@ -125,8 +125,7 @@ test_expect_success 'fetch must not resolve short remote name' '
cd six &&
git init &&
- test_must_fail git fetch .. six:six
-
+ git fetch .. six:six
'
test_expect_success 'create bundle 1' '
--
1.7.8.rc0.128.g31aa4
next prev parent reply other threads:[~2011-11-08 3:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-05 6:01 [PATCH 00/10] Pulling signed tag Junio C Hamano
2011-11-05 6:01 ` [PATCH 01/10] Split GPG interface into its own helper library Junio C Hamano
2011-11-05 6:01 ` [PATCH 02/10] fetch: do not store peeled tag object names in FETCH_HEAD Junio C Hamano
2011-11-05 6:01 ` [PATCH 03/10] merge: notice local merging of tags and keep it unwrapped Junio C Hamano
2011-11-05 6:01 ` [PATCH 04/10] fetch: allow "git fetch $there v1.0" to fetch a tag Junio C Hamano
2011-11-05 6:01 ` [PATCH 05/10] tests: distinguish merges of tags and commits Junio C Hamano
2011-11-05 6:01 ` [PATCH 06/10] refs DWIMmery: use the same rule for both "git fetch" and others Junio C Hamano
2011-11-05 6:01 ` [PATCH 07/10] fmt-merge-msg: avoid early returns Junio C Hamano
2011-11-05 6:01 ` [PATCH 08/10] fmt-merge-msg: package options into a structure Junio C Hamano
2011-11-05 6:01 ` [PATCH 09/10] fmt-merge-msg: Add contents of merged tag in the merge message Junio C Hamano
2011-11-05 8:43 ` Johannes Sixt
2011-11-06 6:03 ` Junio C Hamano
2011-11-05 6:01 ` [PATCH 10/10] merge: force edit mode when merging a tag object Junio C Hamano
2011-11-05 9:27 ` [PATCH 00/10] Pulling signed tag Nguyen Thai Ngoc Duy
2011-11-08 3:00 ` [PATCH v2 00/12] Pulling signed/annotated tags Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 01/12] Split GPG interface into its own helper library Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 02/12] fetch: do not store peeled tag object names in FETCH_HEAD Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 03/12] merge: notice local merging of tags and keep it unwrapped Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 04/12] fetch: allow "git fetch $there v1.0" to fetch a tag Junio C Hamano
2011-11-08 3:00 ` Junio C Hamano [this message]
2011-11-08 3:00 ` [PATCH v2 06/12] fmt-merge-msg: avoid early returns Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 07/12] fmt-merge-msg: package options into a structure Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 08/12] fmt-merge-msg: Add contents of merged tag in the merge message Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 09/12] merge: make usage of commit->util more extensible Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 10/12] merge: record tag objects without peeling in MERGE_HEAD Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 11/12] commit: copy merged signed tags to headers of merge commit Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 12/12] merge: force edit mode when merging a tag object Junio C Hamano
2011-11-08 4:20 ` [PATCH v2 00/12] Pulling signed/annotated tags Linus Torvalds
2011-11-08 5:10 ` Junio C Hamano
2011-11-08 5:31 ` Linus Torvalds
2011-11-08 5:37 ` Junio C Hamano
2011-11-08 21:45 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1320721245-13223-6-git-send-email-gitster@pobox.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).