git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Namhyung Kim <namhyung@gmail.com>
Subject: Re: [PATCH] find_unique_abbrev(): honor caller-supplied "len" better
Date: Thu, 10 Mar 2011 17:16:25 -0800	[thread overview]
Message-ID: <AANLkTikPxSspRFQWke4=u55cmmHw8NsyizeH2gL1kD0y@mail.gmail.com> (raw)
In-Reply-To: <7vzkp21ocm.fsf@alter.siamese.dyndns.org>

On Thu, Mar 10, 2011 at 4:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> How many characters do we need to name master uniquely today?
>
>    $ ./git -c core.abbrevguard=0 rev-parse --short=1 master
>    83c3c
>
> Ok, so there are more than one object with 83c3 and 83c3c is the absolute
> minimum.

Actually, that's just lucky.

Do this:

  git rev-list --abbrev=4 --abbrev-commit --all --objects | grep '^.........*$'

and you'll see several commits in the git tree that need eight
characters to be unique. The fact that your current 'master' isn't one
of them, and in fact happens to be one that only needs five, is just
pure luck.

So even in the (much smaller) git repo, 7 is not a sufficient unique
minimum even today. Never mind any future guarding.

And your argument fails for exactly that reason: yes, for an
_individual_ SHA1, you may think that "five characters is sufficient",
and when you then use that random number (5) as a basis for forming
your "max 8 character" logic, it fails miserably for other cases.

Now, if the "abbrevguard" was based not one one random data-point, but
on the _whole_ current state of the repository, things would be
different.  Then it would actually become a "let's pick a good default
abbreviation length for this repo". But that's now that it does. The
abbrevguard depends on the one particular SHA1 you're looking at, so
you can actually be asking for a longer abbreviation, but still get a
_shorter_ end result than when you asked for a shorter abbreviation.

IOW, try your example thing not just with "master", but with two
extreme commits. For example, try

  git -c core.abbrevguard=2 rev-parse --short=5 83c3c622
  git -c core.abbrevguard=2 rev-parse --short=4 979f7929

and tell me what you get. I _think_ you should get 7 digits for the
first case, and 8 digits for the second one. Even though you "asked"
for a longer name in the first case, and you had the same abbrevguard.

See what I'm saying? I think that's just insane. And it comes exactly
from the fact that abbreviation ends up being a "local" thing.

                          Linus

  reply	other threads:[~2011-03-11  1:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1PBKT9-0004Uk-Sm@tytso-glaptop>
     [not found] ` <20101028075631.GA7690@elte.hu>
     [not found]   ` <AANLkTi=8SbOZizWpxLg=Bgp7atdgr8MsR6tnRDYr1+eW@mail.gmail.com>
     [not found]     ` <20101028163854.GA15450@elte.hu>
     [not found]       ` <AANLkTin62vAwJxcsrFk6Yn7Q6tzr-D=EmKKwPazuAJ11@mail.gmail.com>
     [not found]         ` <20101028171701.GA18368@elte.hu>
2010-10-28 17:27           ` Minimum git commit abbrev length (Was Re: -tip: origin tree build failure (was: [GIT PULL] ext4 update) for 2.6.37) Ted Ts'o
2010-10-28 18:28             ` Linus Torvalds
2010-10-28 18:54               ` Linus Torvalds
2010-10-29  0:14                 ` Minimum git commit abbrev length (Was Re: -tip: origin tree build failure Brandon Casey
     [not found]         ` <7veiba9ev2.fsf@alter.siamese.dyndns.org>
2011-03-10 22:37           ` [PATCH] find_unique_abbrev(): honor caller-supplied "len" better Junio C Hamano
2011-03-10 23:07             ` Linus Torvalds
2011-03-11  0:40               ` Junio C Hamano
2011-03-11  1:16                 ` Linus Torvalds [this message]
2011-03-11  1:33                   ` Junio C Hamano
2011-03-11  2:21                     ` Linus Torvalds
2011-03-11  3:09                       ` Junio C Hamano
2011-03-11  3:03                     ` Junio C Hamano
2011-03-11  5:22                       ` Jeff King
2011-03-11  5:33                         ` Jeff King
2011-03-11 22:45                       ` Junio C Hamano
2011-03-13 13:30                         ` Namhyung Kim
2011-03-19  1:22                         ` Jay Soffian
2011-03-19 16:24                           ` Namhyung Kim

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='AANLkTikPxSspRFQWke4=u55cmmHw8NsyizeH2gL1kD0y@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=namhyung@gmail.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).