Thread (1 message) 1 message, 1 author, 2017-08-14

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 <hidden>
Date: 2017-08-14 18:57:58

Stefan Beller [off-list ref] writes:
On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
Hi Christoph,

On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help