Re: Git for Windows: mingw.c's strange usage of creation time as ctime?
- Date: Wed, 4 Oct 2017 09:57:10 +0200
- From: Marc Strapetz <marc.strapetz@xxxxxxxxxxx>
- Subject: Re: Git for Windows: mingw.c's strange usage of creation time as ctime?
On 04.10.2017 04:23, Jonathan Nieder wrote:
Marc Strapetz wrote:
compat/mingw.c assigns the Windows file creation time  to Git's
ctime fields at line 591 and at line 705:
buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));
ftCreationTime > ftLastWriteTime is actually possible after copying
a file, so it makes sense to include this timestamp somehow in the
Index, but I think it would be better to use the maximum of
ftLastWriteTime and ftCreationTime here which is less confusing and
closer to Unix's ctime:
buf->st_ctime = max(buf->st_mtime,
Can you say more about the practical effect? Is this causing a bug in
practice, is it a bug waiting to happen, or is it making the code
difficult to understand without any ill effect expected at run time?
It's mainly about understanding: as a Windows guy it is quite tempting
to read "ctime" as "creationTime" and getting this confirmed in code
above. (I guess) based on this understanding I wrote wrong Java code 8
years ago for all platforms. My bad of course that I was not digging
into Unix sources here.
In practice, .git/index timestamps will become more similar to Linux,
getting rid of "strange" old ctime values.
Drawback will be that after such a code update every Index entry will
appear as outdated and the initial "git status" will have to compare all
file contents. If this is not acceptable, a comment for the two
offending lines would make sense.
By the way, do you have core.trustctime set to true or false?
It seems to be set to true by default on Windows and usually I'm not