On Thu, May 15, 2025 at 01:39:59PM -0400, Marc Branchaud wrote:
> > As an end-user, I view "where does the body of this function came
> > from" and "when did I touch this file the last time" quite different
> > and unrelated kind of queries.
>
> I can see them either way, depending on how I squint. I have no objection
> if people want to think of this new operation as
> something-that-is-not-a-blame. But then don't call it blame-tree!
>
> How about last-touch?
The name "blame-tree" is probably my fault, as that's what I called it
in 2012 when I originally wrote it. I don't have access to the adjacent
repos anymore, but I _think_ it was replacing a script that was in fact
called "git-last-modified" or something like that. So it all comes
around. ;)
The debate has mostly been over "blame" here. But I think "tree" is also
inaccurate. Theoretically it can be about any set of paths in the repo,
not just the entries of a single tree. So:
git last-modified Makefile Documentation/Makefile t/Makefile
would be a perfectly valid thing to ask about (and of course a
pathspec like '**Makefile' would be a simpler way to do so). The word
"tree" was there because the original use case at GitHub was getting
those values for all of the entries in a particular tree.
But conceptually it is just about expanding a pathspec into a set of
paths, and then traversing and reporting the last time each path was
modified. It _almost_ fits into the "git-log" family, which is all about
traversing and pathspecs. The output is a bit different, but I almost
wonder if it would work as an option to continuously limit the pathspec.
Something like:
$ git log --format=%H --last-modified --raw '**Makefile'
89d557b950c7a0581c12452e8f9576c45546246b
:100644 100644 13f9062a05 c4d21ccd3d M Makefile
[ skip a bunch of commits that touched only Makefile, nothing else ]
a7fa5b2f0ccb567a5a6afedece113f207902fa6f
:100644 100644 6485d40f62 b109d25e9c M Documentation/Makefile
[ skip more; now this one is interesting, because one commit touches a
bunch of files! It also touches Documentation/Makefile, but we'd
have already narrowed our pathspec to forget about it by this point ]
5309c1e9fb399c390ed36ef476e91f76f6746fa9
:100644 100644 3e67552cc5 97ce9c92fb M contrib/credential/libsecret/Makefile
:100644 100644 238f5f8c36 0948297e20 M contrib/credential/osxkeychain/Makefile
:100644 100644 6e992c0866 5b795fc9fe M contrib/credential/wincred/Makefile
:100644 100644 f2be7cc924 33c2ccc9f7 M contrib/diff-highlight/Makefile
:100644 100644 5ff5275496 2a98541477 M contrib/diff-highlight/t/Makefile
:100644 100644 4e603512a3 497ac434d6 M contrib/mw-to-git/Makefile
:100644 100644 f422203fa0 6c9f377caa M contrib/mw-to-git/t/Makefile
:100644 100644 52b84ba3d4 691737e76b M contrib/persistent-https/Makefile
:100644 100644 093399c788 2a85f5ee84 M contrib/subtree/t/Makefile
:100644 100644 667c39ed56 6c5a12bc32 M git-gui/Makefile
:100644 100644 749aa2e7ec e656b0d2b0 M git-gui/po/glossary/Makefile
:100644 100644 6911c2915a 4ff4ed0616 M t/interop/Makefile
:100644 100644 e4808aebed 9b3090c4ed M t/perf/Makefile
:100644 100644 bd1e9e30c1 722755338d M templates/Makefile
[ ... end immediately without traversing further here, since all
paths have been reported ... ]
I dunno. I just made that up. The output is obviously quite different
than blame-tree produces, but it would be easy-ish to collect it in the
same way. And it's much more flexible, because you could use --format
and diff options to report as much or as little about each commit as
you'd want.
It is a bit different from regular log, though, in that we'd expand the
pathspec at the very start, rather than applying it continuously as we
traverse (otherwise we could never end early, since we'd never know if
there was a "foo/Makefile" deep in history).
So you could argue that "git last-modified" could also just take
format and diff output options. ;)
-Peff
