git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>, Bert Wesarg <bert.wesarg@googlemail.com>
Cc: Michael J Gruber <git@drmicha.warpmail.net>, git@vger.kernel.org
Subject: Re: [PATCH] remote.c: use shorten_unambiguous_ref
Date: Tue, 14 Apr 2009 09:55:08 -0700	[thread overview]
Message-ID: <7vprff41lf.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20090410171458.GA26478@sigill.intra.peff.net> (Jeff King's message of "Fri, 10 Apr 2009 13:14:58 -0400")

Jeff King <peff@peff.net> writes:

> Hmm. I was thinking we might be able to just do away with prettify_ref,
> but I didn't consider the fact that we need to prettify remote things. I
> think you could still unambiguously prettify the local half of those
> callsites, though.
>
> Given that the two functions are closely related, should we perhaps
> rename them to
>
>   const char *shorten_ref(const char *);
>   const char *shorten_ref_unambiguous(const char *);
>
> ? The implementations are quite different, with prettify_ref not really
> respecting the ref lookup rules, but rather just considering a few
> pre-determined bits of the hierarchy as uninteresting. It shouldn't be
> that hard to have them both use the same implementation, like:
>
>   const char *shorten_ref(const char *, int unambiguous);

I was hoping that a single "shorten" function that does not even take
"unambiguous" parameter would be used by almost everybody.  As far as I
can see, Bert's "rev-parse --abbrev-ref" RFC is the only caller that might
need to use a value different from warn_ambiguous_refs, and all the other
existing callers (including fill_tracking_info() for "upstream" report by
git-branch) do not have to pass "0" but can use the default.  IOW, we can
have:

	const char *shorten_ref_unambiguous(const char *ref, int strict);
	const char *shorten_ref(const char *ref)
        {
        	return shorten_ref_unambiguous(ref, warn_ambiguous_refs);
	}

and only specialized callers that really care use shorten_ref_unambiguous
(without Bert's [PATCH-RFC 3/2] we do not have any such specialized
caller, I think).

But I am not sure how well prettify_ref() fits into this picture.  It is
called only from transport and is meant to deal with refs that exist on
the remote side, so ambiguity check against our local namespace would not
make much sense.  We could:

	const char *shorten_ref_internal(const char *ref, int mode);
	const char *shorten_ref(const char *ref)
        {
		unsigned mode = warn_ambiguous_refs ? SHORTEN_STRICT : 0;
        	return shorten_ref_internal(ref, mode);
	}
	const char *prettify_ref(const char *ref)
        {
        	return shorten_ref_internal(ref, SHORTEN_PREFIX_ONLY);
        }

and have the SHORTEN_PREFIX_ONLY logic inherit from what the current
prettify_ref() does, but at that point it I do not think it makes sense
anymore.

  parent reply	other threads:[~2009-04-14 16:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-09 15:33 [PATCH] remote.c: use shorten_unambiguous_ref Michael J Gruber
2009-04-10 17:14 ` Jeff King
2009-04-14 12:55   ` Michael J Gruber
2009-04-15  8:03     ` Jeff King
2009-04-14 16:55   ` Junio C Hamano [this message]
2009-04-14 18:18     ` Bert Wesarg
2009-04-15  8:12     ` Jeff King

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=7vprff41lf.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=bert.wesarg@googlemail.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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).