Message ID | cover.1730366765.git.karthik.188@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | packfile: avoid using the 'the_repository' global variable | expand |
Hi Karthik,
On Thu, Oct 31, 2024 at 10:39:43AM +0100, Karthik Nayak wrote:
> Range-diff against v3:
Skimming the range-diff, this new version looks good to me. It would be
nice to hear from another reviewer or two before we start merging it
down, but I think that this is looking good to me.
Thanks for working on this!
Thanks,
Taylor
On Thu, Oct 31, 2024 at 04:05:56PM -0400, Taylor Blau wrote: > Hi Karthik, > > On Thu, Oct 31, 2024 at 10:39:43AM +0100, Karthik Nayak wrote: > > Range-diff against v3: > > Skimming the range-diff, this new version looks good to me. It would be > nice to hear from another reviewer or two before we start merging it > down, but I think that this is looking good to me. Hmmph. I spoke too soon, this new version appears to break CI on Windows, and thus broke the builds of 'jch' (and 'seen', by extension). https://github.com/ttaylorr/git/actions/runs/11602969593/job/32309061019 Can you have a look? In the meantime, I'm going to move this out of 'jch' to let CI run there again. Thanks, Taylor
Taylor Blau <me@ttaylorr.com> writes: > On Thu, Oct 31, 2024 at 04:05:56PM -0400, Taylor Blau wrote: >> Hi Karthik, >> >> On Thu, Oct 31, 2024 at 10:39:43AM +0100, Karthik Nayak wrote: >> > Range-diff against v3: >> >> Skimming the range-diff, this new version looks good to me. It would be >> nice to hear from another reviewer or two before we start merging it >> down, but I think that this is looking good to me. > > Hmmph. I spoke too soon, this new version appears to break CI on > Windows, and thus broke the builds of 'jch' (and 'seen', by extension). > > https://github.com/ttaylorr/git/actions/runs/11602969593/job/32309061019 > > Can you have a look? > > In the meantime, I'm going to move this out of 'jch' to let CI run there > again. > Thanks for letting me know, I think the fix is simply diff --git a/packfile.c b/packfile.c index f626d38071..737cd60377 100644 --- a/packfile.c +++ b/packfile.c @@ -27,8 +27,8 @@ #include "pack-objects.h" struct packfile_config { - unsigned long packed_git_window_size; - unsigned long packed_git_limit; + unsigned long long packed_git_window_size; + unsigned long long packed_git_limit; }; #define PACKFILE_CONFIG_INIT \ Tested it on GitLab's CI too this time. https://gitlab.com/gitlab-org/git/-/jobs/8248707713 Will send in a new version including the fix tomorrow! Karthik
On Fri, Nov 01, 2024 at 11:07:48AM -0500, karthik nayak wrote: > Thanks for letting me know, I think the fix is simply > > diff --git a/packfile.c b/packfile.c > index f626d38071..737cd60377 100644 > --- a/packfile.c > +++ b/packfile.c > @@ -27,8 +27,8 @@ > #include "pack-objects.h" > > struct packfile_config { > - unsigned long packed_git_window_size; > - unsigned long packed_git_limit; > + unsigned long long packed_git_window_size; > + unsigned long long packed_git_limit; > }; > > #define PACKFILE_CONFIG_INIT \ Wait, why did these change from "size_t" to "unsigned long" in your series in the first place? If the goal is moving them into a struct, they should otherwise retain the same types, no? Two asides, one for your series and one #leftoverbits: 1. Since these are now fields of packfile_config, do they need the long packed_git_ prefix anymore? Just window_size and limit would be nicer, I'd think. 2. I can imagine you might have used "unsigned long" because they are parsed with git_config_ulong(). That is OK on Linux, where size_t and "unsigned long" are the same size (either 32- or 64-bits). But on Windows I think it means that you cannot configure a window larger than 4GB on a 64-bit system. Or ironically you cannot set a total limit larger than 4GB, even though the default is 32TB. ;) -Peff
Jeff King <peff@peff.net> writes: > On Fri, Nov 01, 2024 at 11:07:48AM -0500, karthik nayak wrote: > >> Thanks for letting me know, I think the fix is simply >> >> diff --git a/packfile.c b/packfile.c >> index f626d38071..737cd60377 100644 >> --- a/packfile.c >> +++ b/packfile.c >> @@ -27,8 +27,8 @@ >> #include "pack-objects.h" >> >> struct packfile_config { >> - unsigned long packed_git_window_size; >> - unsigned long packed_git_limit; >> + unsigned long long packed_git_window_size; >> + unsigned long long packed_git_limit; >> }; >> >> #define PACKFILE_CONFIG_INIT \ > > Wait, why did these change from "size_t" to "unsigned long" in your > series in the first place? If the goal is moving them into a struct, > they should otherwise retain the same types, no? > > Two asides, one for your series and one #leftoverbits: > > 1. Since these are now fields of packfile_config, do they need the > long packed_git_ prefix anymore? Just window_size and limit would > be nicer, I'd think. > Moving them to repo_settings means we'd have to keep the long names, otherwise, I agree the shorter names would be better. > 2. I can imagine you might have used "unsigned long" because they are > parsed with git_config_ulong(). That is OK on Linux, where size_t > and "unsigned long" are the same size (either 32- or 64-bits). But > on Windows I think it means that you cannot configure a window > larger than 4GB on a 64-bit system. Or ironically you cannot set a > total limit larger than 4GB, even though the default is 32TB. ;) Yup that's the reason I changed them. TIL about size_t and how it works. Thanks, I'll change the types accordingly and push a new version soon. > > -Peff
On Mon, Nov 04, 2024 at 01:39:31AM -0800, karthik nayak wrote: > > 2. I can imagine you might have used "unsigned long" because they are > > parsed with git_config_ulong(). That is OK on Linux, where size_t > > and "unsigned long" are the same size (either 32- or 64-bits). But > > on Windows I think it means that you cannot configure a window > > larger than 4GB on a 64-bit system. Or ironically you cannot set a > > total limit larger than 4GB, even though the default is 32TB. ;) > > Yup that's the reason I changed them. TIL about size_t and how it works. > Thanks, I'll change the types accordingly and push a new version soon. Thanks. I think I got so busy talking about the issue that I forgot to mention why I think this is potential #leftoverbits: we probably ought to be parsing that config with git_config_ssize_t() or similar. But that is outside the scope of your series. -Peff