summaryrefslogtreecommitdiff
path: root/perl
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2011-11-04 14:14:05 -0700
committerJunio C Hamano <gitster@pobox.com>2011-11-07 15:34:30 -0800
commitdd621df9cde83fc08f9d3924b793b989b8f8a313 (patch)
tree6e72fdc015b51c9871a0f3f30b03a57fc6f7d338 /perl
parent47d84b6abcd2fbb2e84495663407829c9bb0da67 (diff)
downloadgit-dd621df9cde83fc08f9d3924b793b989b8f8a313.tar.gz
refs DWIMmery: use the same rule for both "git fetch" and others
"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>
Diffstat (limited to 'perl')
0 files changed, 0 insertions, 0 deletions