Re: Git should preserve modification times at least on request

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Peter,

On Mon, 19 Feb 2018, Peter Backes wrote:

> On Mon, Feb 19, 2018 at 10:58:12PM +0100, Johannes Schindelin wrote:
> > Since you already assessed that it shouldn't be hard to do, you
> > probably want to put your money where your mouth is and come up with a
> > patch, and then offer it up for discussion on this here mailing list.
> 
> Well, it would be good to discuss this a bit beforehand, since my time 
> is wasted if there's no chance to get it accepted. Perhaps there is 
> some counterargument I don't know about.

Oh, sorry. I understood your mail as if you had told the core Git
developers that they should implement the feature you desire. I did not
understand that you hinted at a discussion first, and that you would then
go and implement the feature you asked for.

> Is there some existing code that could be used? I think I read 
> somewhere that git once did preserve mtimes, but that this code was 
> removed because of the build tool issues. Perhaps that code could 
> simply be put back in, and surrounded by conditions.

I don't think that code was ever there. Maybe you heard about some file
mode being preserved overzealously (we stored the octal file mode
verbatim, but then decided to store only 644 or 755).

(This is to add to Theodore's reply, giving a bit more depth.)

As you can see from the code decoding a tree entry:

https://github.com/git-for-windows/git/blob/e1848984d/tree-walk.c#L25-L52

there is no mtime at all in the on-disk format of tree objects. There is
the hash, the mode, and the file name.

As your main use case would be stashing and unstashing (which uses tree
objects as storage format), this means you would have to find a different
way to store the information you desire.

If I were you, and if I had the time to implement this feature, I would go
about it by adding a note (using `git notes` from a script first, but only
for proof of concept, because I saw too many things go wrong with Unix
shell scripts in production) for the tree object, say, in
refs/notes/mtimes. I would probably invent a file format
(`<mtime><TAB><path><LF>`) to store the information, and for starters I
would only store the mtimes of the files that were stashed, then extend
the script into a full Git builtin with a subcommand that can generates
these notes, a subcommand to replay them, and a subcommand to inspect
them.

Then I would extend `git-stash.sh` to take an option (and later, to heed a
new config setting to do this automatically) to generate those mtime notes
for the newest stash's top-level tree object (storing only the times of
the files that were modified by the `stash` command), and to replay them
if such an mtime note is found for the stash that is being applied.

You will not be able to convince the core Git developers to make this the
default, I don't think. But if you make it an opt-in as I outlined above,
I believe your chances would be good to get that feature if you put in the
effort to implement it.

Oh, and if you implement the feature using notes, the same feature can be
used not only for stashing and unstashing. These notes are maintained in
regular Git refs, i.e. they can be shared. And since those notes would be
for tree objects, you could even apply the mtimes on a fresh clone, if
you have a use case for that.

Ciao,
Johannes