Re: [git patches] libata updates, GPG signed (but see admin notes)

Junio C Hamano <gitster@pobox.com> writes:

If we really wanted to go this route, the attached single-liner should be sufficient for the DWIMmery.

Note that the DWIMmery rules for "git fetch" and local "git rev-parse" are still different even after this patch.

"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 does 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.

If we really wanted to, we could 

	#define ref_fetch_rules ref_rev_parse_rules
 
in cache.h and remove the array's declaration from cache.h and its
definition from refs.c to really unify the two, but I haven't thought
things through.

-- >8 --
Subject: [PATCH] fetch: allow "git fetch $there v1.0" to fetch a tag

You can already do so with "git fetch $there tags/v1.0" but if it is not ambiguous there is no reason to force users to type more.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 refs.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)