> I wish they had not gone with uint32_t for storing mtimes, since they now have to deal with the 2038 problem, sometime in the future.
Since uint32_t is unsigned, wouldn't it be the Y2106 problem instead?
> I am surprised they didn't directly use time_t, so that they wouldn't have to deal with this (since some platforms have already gone to 64 bit time_t)
You mentioned the problem yourself without noticing: some platforms have gone to 64-bit time_t, but others haven't. This is a file format, which can be shared by multiple platforms, so it cannot use types which change size depending on the platform.
That would double the disk space use of that particular file, for something which won't be necessary for more than 80 years (the mtime of a git object or pack file will always be in the past, unless the computer clock is wrong); and when that time arrives, a new file format can be defined (and the old format kept as read-only, with new data being written to the new file).
Since uint32_t is unsigned, wouldn't it be the Y2106 problem instead?
> I am surprised they didn't directly use time_t, so that they wouldn't have to deal with this (since some platforms have already gone to 64 bit time_t)
You mentioned the problem yourself without noticing: some platforms have gone to 64-bit time_t, but others haven't. This is a file format, which can be shared by multiple platforms, so it cannot use types which change size depending on the platform.