Re: Feature Request: Allow to stash push and pop file modification times to avoid rebuilds

[Junio C Hamano <gitster@pobox.com>]

Ridil culous <reallyridilculous@gmail.com> writes:

> "git stash push"
> later followed by
> "git stash pop"
> does restore files but doesn't restore file modification times.

It is very consistent with everything Git (the version control
system) does to working tree files, e.g. "git restore -- file", "git
switch branch".  Like it or not, build systems that avoids
recomputation of material derived from source files (which are kept
in the version control systems, like Git) often work by comparing
file timestamps.  

Imagine that you had iffy changes in the working tree files, and
then did a build.  The build artifacts are based on the souce with
those iffy changes.  Then you do "stash push" to tentatively remove
the changes.  Perhaps you make a build again.  You want your new
build artifacts to reflect the fact that you no longer have those
iffy changes in the source, so "stash push" should update the file
timestamp when it removes the changes.  Now you would do "stash
pop", because you are convinced that those changes that you earlier
thought were iffy are indeed good ones.

Now what timestamp should "stash pop" give to the working tree files
in this case?  The contents of the file probably is identical to the
timestamp of the working tree files immediately before "stash push"
was run.  If we restore the original timestamp, because it is way
older than the build artifacts of your second build (which was done
after "stash push"), the build artifacts would not be recreated.
The source has those changes (that used to be deemed iffy but now
they are OK), the build artifact does not.

Unless your build system bases its rebuilding decisions on the
contents, not timestamps, it is very much essential not to
artificially muck with the file timestamp when your source control
system rewrites the files in your working tree to avoid broken
builds, I would have to say.