On Wed, Feb 21, 2018 at 11:44:13PM +0100, Ævar Arnfjörð Bjarmason wrote: > If it were added as a first-level feature to git it would present a lot > of UX confusion. E.g. you run "git add" and it'll be showing the mtime > somehow, or you get a formatted patch over E-Mail and it doesn't only > include the commit time but also times for individual files. But that's pretty standard. patch format has timestamp fields for precisely this purpose: % echo a > x % echo b > y % diff -u x y --- x 2018-02-21 23:56:29.574029523 +0100 +++ y 2018-02-21 23:56:31.430003389 +0100 @@ -1 +1 @@ -a +b At present, git simply leaves those fields blank... > The VC systems that had this feature in the past were centralized, so > they could (in theory anyway) ensure that timestamps were monotonically > increasing. This won't be the case with git, we have plenty of timestamp > drift in e.g. linux.git and other git repos. I don't see where monotonicity would be an issue any more than it is for centralized version control systems. Even in the centralized setting, monotonicity is not guaranteed, since you might have local timestamps deviating from the repository; you might have added a line, compiled, and removed it again later on, without running make again. Now if you checkout changes from the repository, and it sets the timestamp, that timestamp might be older than before the compile, and the file would not be rebuilt if you run make. So you cannot avoid those issues in centralized setttings either. > So if these mtimes were used by default they'd interact badly with stuff > like "make" in those cases, because you might check out a modified > version with a timestamp in the past. That's very clearly the case, and I have stressed in my initial email that I fully agree with the reasoning of the FAQ in this regard. It is, however, merely an argument against *restoring* the timestamps *by default*, to comply with the principle of least astonishment. It is, by itself, not an argument against *storing* the timestamps, let alone against restoring them *on request*. For the initial checkout, it should not even be harmful to restore the timestamps by default. > any case, I just wanted to point out a workaround (but then digressed > into critiquing the idea above...). Well, Johannes's proposed solution seems pretty reasonable and realistic to me. Thanks to Phillip's hint about unquote_path() in Git.pm it seems I now have all the needed ingredients to implement this feature. Best wishes Peter -- Peter Backes, rtc@xxxxxxxxxxxxxxxxxxx
