On Tue, 15 Sep 2020 at 23:14, Junio C Hamano <gitster@xxxxxxxxx> wrote: > jnareb@xxxxxxxxx (Jakub Narębski) writes: > > > Those are patches that are part of GSoC project of Shourya Shukla: > > 'Convert submodule to builtin'. > > ... > > Those are patches that are part of GSoC project of Hariom Verma: > > 'Unify ref-filter formats with other --pretty formats' > > Yes and yes. What is your intention for highlighting that these two > are GSoC originated projects, by the way? It was to compare the final status (merged vs not merged) of all Git's GSoC 2020 projects... in a bit clumsy way, I admit. [...] > > Because corrected commit date offsets are not monotone, that is after > > value that doesn't fit in 32 bits (in parent) there can be one that does > > (in child). It is extremely unlikely that in real repositories there > > would be that large corrections needed, but it can happen in theory, and > > therefore we need some way to handle overflow if we choose this option. > > And of course we should test that overflow handling works correctly. > > My gut feeling is that overflow handling needs to be there whether the > field is 32-bit or 64-bit. Not if the size on-disk is the same as the size in memory: timestamp_t is usually 64 bit (and even unsigned 64 bit epoch would be enough - its range is over twenty times the present age of the universe per direction). Best, -- Jakub Narębski
