From: Namhyung Kim <namhyung@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] blame: honor core.abbrevguard
Date: Tue, 08 Mar 2011 10:38:16 +0900 [thread overview]
Message-ID: <1299548296.1467.18.camel@leonhard> (raw)
In-Reply-To: <7vipvuzau2.fsf@alter.siamese.dyndns.org>
Hi,
2011-03-07 (월), 16:59 -0800, Junio C Hamano:
> Namhyung Kim <namhyung@gmail.com> writes:
>
> > Commit 72a5b561 ("core.abbrevguard: Ensure short object names stay
> > unique a bit longer") introduced this config variable to make object
> > name unambiguously. Use it.
> >
> > Signed-off-by: Namhyung Kim <namhyung@gmail.com>
> > ---
> > v2:
> > - re-init 'length' in every loop
>
> In this codepath, we only aim to make sure that the shortened object name
> is of the same length. By choosing hardcoded 8, the original clearly
> declares that we do not _care_ about the uniqueness.
>
Just out of curiousity, where did the number come from? I guess
DEFAULT_ABBREV + '^' ?
> The abbrev-guard that adds to the length that ensures the uniqueness in
> the particular repository has a very different semantics. It only makes
> sense if you add to a length that you know would make the object names
> minimally unique. Adding it to hardcoded 8 does not make it less
> ambiguous the same way as the configuration variable intends to do.
>
> So I am not entirely happy with this patch.
>
> Besides, when OUTPUT_LONG_OBJECT_NAME is specified, the value this
> variable holds is _not_ "uniq_length", so the name of the variable is not
> quite correct. We colloquially call the object name "sha1" in the code,
> so "sha1_length" would be a better name for it.
>
OK. I was not happy with the name, too. :)
> If we _were_ to do a change that uses the configuration variable, I would
> imagine that it would be a part of a change that makes sure that the
> shortened object names in the output actually uniquely identify the
> commits. It would involve find_unique_abbrev() for as many commits as the
> number of lines in the blamed range at most (and at that point the abbrev
> guard would automatically taken into account because find_unique_abbrev()
> already does so) before calling "output()"; I suspect that find_alignment()
> is the right function to do so, as that is where the column alignment
> logic all happens.
>
> It would probably need to be introduced as a new feature, with its own
> command line option, similar to -l option that forces the full 40-hex
> output.
>
Looks Great. How about -u/--unique? I'm also thinking about --abbrev
too, isn't it useful at all?
> So thanks for a patch, but I don't think we would want to take it in the
> current shape.
Thanks for your kindly comment.
--
Regards,
Namhyung Kim
prev parent reply other threads:[~2011-03-08 1:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-07 4:35 [PATCH] blame: honor core.abbrevguard Namhyung Kim
2011-03-07 5:22 ` [PATCH v2] " Namhyung Kim
2011-03-08 0:59 ` Junio C Hamano
2011-03-08 1:38 ` Namhyung Kim [this message]
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=1299548296.1467.18.camel@leonhard \
--to=namhyung@gmail.com \
--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).