Restore modification times after vc operations

Question

Make is purely timestamp-oriented: if a source is older than its target, the target gets rebuilt. This can cause long recompilations in big applications if one does some major version control detour.

Let me give you an example. Suppose I have an old feature branch which didn't get merged yet, and I want to see how it's doing. So starting from master, I would checkout that branch, then merge master into it, then compile. All very fine, and if the feature was small, then differences vs. master should be small as well. Except that if the feature branch was really old, I undid and then redid a lot of modifications in the file system.

As a second example, you might imagine bisecting large portions of code while looking for some complicated condition which is beyond git pickaxe but which does not require recompiling the code. After I found what I was looking for, I should be back at my master branch. But in between, many files might have been modified if the bisection window was large enough.

So what I'd like to know is this: is there some tool which would allow me to take a snapshot of modification times up front, and restore the mtimes for those files whose content was restored by these operations. Of course I'd have to tell it explicitely when I'm done, since the whole point of this is that the files may get changed in between.

I guess I'm looking for a tool which integrates with git, because for a generic tool, taking snapshots of a big source tree would also take considerable time, so it would have to be something which can keep track of files as they get modified, e.g. using some hook. On the other hand, if git status has to check the content of every file as well, then maybe the cost of a generic tool isn't that high.

Is there such a tool, or would I have to write one myself?

Note that Checking out old file WITH original create/modified timestamps does not seem exactly what I want, and would take too long in any case.

Answer 1

Finding no suitable tool, I ended up writing my own tool. It turned out to be less difficult than I thought, mostly because hashing the content of all these files was less expensive than I thought, at least with hot file system caches.

Answer 2

If the production of derived versions is too costly, and if this kind of branch switching and going back to some old baseline is something you do frequently (why?) then you should consider checking in these derived versions along with their inputs, and baseline-label them.