git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Elijah Newren <newren@gmail.com>
Cc: Stefan Beller <sbeller@google.com>, git <git@vger.kernel.org>
Subject: Re: [PATCH 2/4] Remove silent clamp of renameLimit
Date: Sat, 11 Nov 2017 17:32:53 +0000	[thread overview]
Message-ID: <20171111173253.idmyypjevwqblica@genre.crustytoothpaste.net> (raw)
In-Reply-To: <CABPp-BHvveKW+UzTZqLq5h0bVUJLPqYpGu0CWQpYjHzzDbEWww@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

On Sat, Nov 11, 2017 at 08:39:11AM -0800, Elijah Newren wrote:
> Thanks for pointing out unsigned_mult_overflows; I was unaware of it.
> I think I'd prefer to not use it though; the fact that I had a case
> that genuinely needed a value greater than 2^31 (at least before my
> performance patches) meant that a slightly bigger repo is going to
> eventually need a value over 2^32, so I think we should just cast to a
> type that can hold it.

That's fine.  I had considered this in the context of 64-bit values, but
I suppose that the likelihood of us hitting 2**64 iterations (and
performing reasonably as well) is unlikely.

> I'm curious why you suggest size_t, though.  I have always associated
> that with an amount of memory that will be used, and there's no
> allocation based on this result.  Was I wrong to make that
> association, or is there another good reason here?

I usually like size_t for values that are unsigned and don't need to be
fixed size because it's usually the largest efficient unsigned type.
However, if you want something to handle items larger than 2**32, then I
agree that it's maybe not a great idea if we want it to work on 32-bit
systems.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]

  reply	other threads:[~2017-11-11 17:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-10 17:39 [PATCH 0/4] Fix issues with rename detection limits Elijah Newren
2017-11-10 17:39 ` [PATCH 1/4] sequencer: Warn when internal merge may be suboptimal due to renameLimit Elijah Newren
2017-11-13  5:16   ` Junio C Hamano
2017-11-10 17:39 ` [PATCH 2/4] Remove silent clamp of renameLimit Elijah Newren
2017-11-10 18:26   ` Stefan Beller
2017-11-10 18:36     ` Elijah Newren
2017-11-10 23:42       ` brian m. carlson
2017-11-11 16:39         ` Elijah Newren
2017-11-11 17:32           ` brian m. carlson [this message]
2017-11-10 17:39 ` [PATCH 3/4] progress: Fix progress meters when dealing with lots of work Elijah Newren
2017-11-13  5:24   ` Junio C Hamano
2017-11-13 20:05     ` Elijah Newren
2017-11-14  1:18       ` Junio C Hamano
2017-11-10 17:39 ` [PATCH 4/4] sequencer: Show rename progress during cherry picks Elijah Newren
2017-11-13  5:25   ` Junio C Hamano

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=20171111173253.idmyypjevwqblica@genre.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=sbeller@google.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.
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).