On 2019-04-08 21:36, Matheus Tavares Bernardino wrote: > On Mon, Apr 8, 2019 at 4:19 PM Philip Oakley <philipoakley@xxxxxxx> wrote: >> >> Hi Matheus >> >> On 08/04/2019 18:04, Matheus Tavares Bernardino wrote: >>>> Another "32-bit problem" should also be expressly considered during the >>>> GSoC work because of the MS Windows definition of uInt / long to be only >>>> 32 bits, leading to much of the Git code failing on the Git for Windows >>>> port and on the Git LFS (for Windows) for packs and files greater than >>>> 4Gb.https://github.com/git-for-windows/git/issues/1063 >> >>> Thanks for pointing it out. I didn't get it, thought, if your >>> suggestion was to also propose tackling this issue in this GSoC >>> project. Was it that? I read the link but it seems to be a kind of >>> unrelated problem from what I'm planing to do with the pack access >>> code (which is tread-safety). I may have understood this wrongly, >>> though. Please, let me know if that's the case :) >>> >> The main point was to avoid accidental regressions by re-introducing >> simple 'longs' where memsized types were more appropriate. >> >> Torsten has already done a lot of work at >> https://github.com/tboegi/git/tree/tb.190402_1552_convert_size_t_only_git_master_181124_mk_size_t > > Got it. Thanks, Philip! > >> HTH >> Philip >> (I'm off line for a few days) Thanks for the reminder - I will probably send something out the next days/weeks.
