> I think [`git log -n1 -- <path>`] is the fastest way to get the most recent commit time on a single file?
In terms of machine time? I'd guess so, but I'd also guess calling it for each of `git ls-files` is not the fastest way to get the most recent commit of all the files in a typical scenario (large repo, recent time of interest, most files not changed that recently). And especially if you're okay assuming the most recent commit by parentage is the one you want (even if parentage doesn't match chronological order); then filtering with `git log --name-only --since` (no path argument) seems better. A `git log` post-processing script could also stop early if it's seen a commit for each the files of interest (again, assuming you don't want to return a later date that is attached to an ancestor commit).
Anyway, cool tool, and it's rare that I would actually care about the machine efficiency of this pipeline enough to bother with the approach I just described.
Yeah totally right. I just don't know enough about git to figure it out. But a sibling commenter helped a lot.
And yeah perf probably doesn't matter much. But, like, running my approach on the Rust compile repo takes at least minute on my beefly (if a little dated) machine. But lukasgelbmann's approach only takes about 11 seconds. That's a big improvement.
Yeah though, perf here may not matter much. It's just an example use of bttf that is less than instant. (And it's not really bttf. It's my examples access pattern of git.)