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
