Re: Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 14, 2017, 18:57 UTC
Message-ID: <xmqqk226ugcw.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaYi=mqw615ZHiNAbDdnnKLawzZDy3ecLYDVV=e7e5qbQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 22 quoted lines

> On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi Christoph,
>>
>> On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote:
>>
>>> on Windows 64-bit, for a repository having a .pack file > 4GB I get
>>> during cloning:
>>
>> The reason is Git's source code that over-uses the `unsigned long`
>> datatype.
>>
>> In a nearby-thread, an underappreciated effort by Martin Koegler is
>> underway to get the ball rolling in getting it fixed. Maybe you can help
>> making Martin a lot more welcome on the Git mailing list, and maybe even
>> help getting his patches reviewed and integrated?
>
> 'nearby' as in [1] ;-)
>
> [1] https://public-inbox.org/git/1502527643-21944-1-git-send-email-martin@mail.zuhause/
>
> I had the impression the review is going well there?

I do not know if it is "going well", but I do not agree with the "underappreciated" bit at all. I find such a blanket statement toxic and detrimental to the community.

It is true that many topics in flight are broken with a tree-wide change that is presented as a single ball of wax. Unlike the ongoing "struct object_id" effort, which also is tree-wide but tries to find a step-wise refinement to reduce its impact on other topics, it is harder to integrate such a change. But that does not have any relation to how much the effort is appreciated.