git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] remote.c: use shorten_unambiguous_ref
Date: Wed, 15 Apr 2009 04:03:02 -0400	[thread overview]
Message-ID: <20090415080301.GD23332@coredump.intra.peff.net> (raw)
In-Reply-To: <49E487B2.5030606@drmicha.warpmail.net>

On Tue, Apr 14, 2009 at 02:55:14PM +0200, Michael J Gruber wrote:

> >   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);
> 
> Should I rebase this on top of Bert's newer patch (which has the
> signature you suggest)? Currently I don't see any of them in.

It has the same signature, but the meanings are different. My flag meant
"should we bother looking at ambiguity at all?" whereas Bert's flag is
about "how strictly should we be counting ambiguity?".

So really there are three levels, which implies an enum (with none,
loose, and strict). However, calling it with a tri-state flag would be
less convenient, since your logic for the flag is:

  if (we are shortening something non-local)
    flag = none;
  else if (core.warn_ambiguous_refs is not set)
    flag = loose;
  else
    flag = strict;

So you really want to pass the two bits of information separately.

-Peff

  reply	other threads:[~2009-04-15  8:04 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 [this message]
2009-04-14 16:55   ` Junio C Hamano
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=20090415080301.GD23332@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).