git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Git List" <git@vger.kernel.org>, "René Scharfe" <l.s.r@web.de>,
	"Duy Nguyen" <pclouds@gmail.com>
Subject: Re: [PATCH 12/31] fast-import: make hash-size independent
Date: Mon, 11 Feb 2019 22:44:12 -0500	[thread overview]
Message-ID: <CAPig+cQivuPjDztK30QO0xKx1Tx+nYDPzTvgXvi9WVyRX5-aRQ@mail.gmail.com> (raw)
In-Reply-To: <20190212012256.1005924-13-sandals@crustytoothpaste.net>

On Mon, Feb 11, 2019 at 8:23 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> Replace several uses of GIT_SHA1_HEXSZ and 40-based constants with
> references to the_hash_algo.  Update the note handling code here to
> compute path sizes based on GIT_MAX_RAWSZ as well.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
> diff --git a/fast-import.c b/fast-import.c
> @@ -2047,7 +2047,8 @@ static uintmax_t do_change_note_fanout(
> -       char realpath[60];
> +       char realpath[GIT_MAX_RAWSZ * 3];

I wonder if the fixed multiplier deserves a comment explaining that
this is reserving enough space for a hex representation with '/'
between each digit pair plus NUL. Which leads to the next question: Is
there is GIT_MAX_HEXSZ constant? If so, this might be more clearly
represented (or not) by taking advantage of that value.

Also, there are a number of hardcoded 60's in the code earlier in this
file, such as:

    if ((max_packsize && (pack_size + 60 + len) > max_packsize)
        || (pack_size + 60 + len) < pack_size)
        cycle_packfile();

Is that just a coincidence or is it related to the 60 characters
allocated for 'realpath'?

> @@ -2405,7 +2406,7 @@ static void note_change_n(const char *p, struct branch *b, unsigned char *old_fa
>                 char *buf = read_object_with_reference(&commit_oid,
>                                                        commit_type, &size,
>                                                        &commit_oid);
> -               if (!buf || size < 46)
> +               if (!buf || size < the_hash_algo->hexsz)

What exactly did the 46 represent and how does it relate to 'hexsz'?
Stated differently, why didn't this become:

    the_hash_algo->hexsz + 6'

?

> @@ -2456,7 +2457,7 @@ static void file_change_deleteall(struct branch *b)
>  static void parse_from_commit(struct branch *b, char *buf, unsigned long size)
>  {
> -       if (!buf || size < GIT_SHA1_HEXSZ + 6)
> +       if (!buf || size < the_hash_algo->hexsz + 6)

...as it seems to have here...

> @@ -2555,7 +2556,7 @@ static struct hash_list *parse_merge(unsigned int *count)
> -                       if (!buf || size < 46)
> +                       if (!buf || size < the_hash_algo->hexsz)

...but not here.

  reply	other threads:[~2019-02-12  3:44 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12  1:22 [PATCH 00/31] Hash function transition part 16 brian m. carlson
2019-02-12  1:22 ` [PATCH 01/31] t/lib-submodule-update: use appropriate length constant brian m. carlson
2019-02-12  1:22 ` [PATCH 02/31] pack-bitmap: make bitmap header handling hash agnostic brian m. carlson
2019-02-12  1:22 ` [PATCH 03/31] pack-bitmap: convert struct stored_bitmap to object_id brian m. carlson
2019-02-12  1:22 ` [PATCH 04/31] pack-bitmap: replace sha1_to_hex brian m. carlson
2019-02-12  6:37   ` Jeff King
2019-02-13  0:00     ` brian m. carlson
2019-02-14  4:41       ` Jeff King
2019-02-12  1:22 ` [PATCH 05/31] pack-bitmap: switch hard-coded constants to the_hash_algo brian m. carlson
2019-02-12 11:13   ` Ævar Arnfjörð Bjarmason
2019-02-12  1:22 ` [PATCH 06/31] submodule: avoid hard-coded constants brian m. carlson
2019-02-12  1:22 ` [PATCH 07/31] notes-merge: switch to use the_hash_algo brian m. carlson
2019-02-12  1:22 ` [PATCH 08/31] notes: make hash size independent brian m. carlson
2019-02-12  1:37   ` Eric Sunshine
2019-02-12  1:42     ` brian m. carlson
2019-02-12  1:22 ` [PATCH 09/31] notes: replace sha1_to_hex brian m. carlson
2019-02-12  1:22 ` [PATCH 10/31] object-store: rename and expand packed_git's sha1 member brian m. carlson
2019-02-12  3:32   ` Eric Sunshine
2019-02-14  3:33     ` brian m. carlson
2019-02-12  1:22 ` [PATCH 11/31] builtin/name-rev: make hash-size independent brian m. carlson
2019-02-12  1:22 ` [PATCH 12/31] fast-import: " brian m. carlson
2019-02-12  3:44   ` Eric Sunshine [this message]
2019-02-12 23:36     ` brian m. carlson
2019-02-12  1:22 ` [PATCH 13/31] fast-import: replace sha1_to_hex brian m. carlson
2019-02-12  1:22 ` [PATCH 14/31] builtin/am: make hash size independent brian m. carlson
2019-02-12  1:22 ` [PATCH 15/31] builtin/pull: make hash-size independent brian m. carlson
2019-02-12  3:47   ` Eric Sunshine
2019-02-12  1:22 ` [PATCH 16/31] http-push: convert to use the_hash_algo brian m. carlson
2019-02-12  1:22 ` [PATCH 17/31] http-backend: allow 64-character hex names brian m. carlson
2019-02-12  1:22 ` [PATCH 18/31] http-push: remove remaining uses of sha1_to_hex brian m. carlson
2019-02-12  1:22 ` [PATCH 19/31] http-walker: replace sha1_to_hex brian m. carlson
2019-02-12  3:51   ` Eric Sunshine
2019-02-12  1:22 ` [PATCH 20/31] http: replace hard-coded constant with the_hash_algo brian m. carlson
2019-02-12  1:22 ` [PATCH 21/31] http: compute hash of downloaded objects using the_hash_algo brian m. carlson
2019-02-12  1:22 ` [PATCH 22/31] http: replace sha1_to_hex brian m. carlson
2019-02-12  1:22 ` [PATCH 23/31] remote-curl: make hash size independent brian m. carlson
2019-02-12 11:11   ` Ævar Arnfjörð Bjarmason
2019-02-12  1:22 ` [PATCH 24/31] archive-tar: " brian m. carlson
2019-02-12  7:20   ` René Scharfe
2019-02-12 17:33     ` René Scharfe
2019-02-13  0:11       ` brian m. carlson
2019-02-12  1:22 ` [PATCH 25/31] archive: convert struct archiver_args to object_id brian m. carlson
2019-02-12  1:22 ` [PATCH 26/31] refspec: make hash size independent brian m. carlson
2019-02-12  1:22 ` [PATCH 27/31] builtin/difftool: use parse_oid_hex brian m. carlson
2019-02-12  8:27   ` Eric Sunshine
2019-02-12  1:22 ` [PATCH 28/31] dir: make untracked cache extension hash size independent brian m. carlson
2019-02-12 11:08   ` Ævar Arnfjörð Bjarmason
2019-02-13  0:30     ` brian m. carlson
2019-02-12  1:22 ` [PATCH 29/31] read-cache: read data in a hash-independent way brian m. carlson
2019-02-12  1:22 ` [PATCH 30/31] Git.pm: make hash size independent brian m. carlson
2019-02-12 10:59   ` Ævar Arnfjörð Bjarmason
2019-02-18 19:09     ` brian m. carlson
2019-02-18 21:00       ` Ævar Arnfjörð Bjarmason
2019-02-12  1:22 ` [PATCH 31/31] gitweb: " brian m. carlson
2019-02-12 10:57   ` Ævar Arnfjörð Bjarmason
2019-02-12 11:15 ` [PATCH 00/31] Hash function transition part 16 Ævar Arnfjörð Bjarmason

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPig+cQivuPjDztK30QO0xKx1Tx+nYDPzTvgXvi9WVyRX5-aRQ@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=pclouds@gmail.com \
    --cc=sandals@crustytoothpaste.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).