Re: [PATCH RFC v2 0/5] Introduce git-last-modified(1) command

[Toon Claes <toon@iotcl.com>]

Toon Claes <toon@iotcl.com> writes:

> You raise a good point here. Let's compare:
>
> $ git ls-tree HEAD -- refs.c refs.h Documentation/git-last-modified.adoc Documentation/git-config.adoc
> 100644 blob 936e0c5130fe7d67f645501fbb9e70b94b437f54	Documentation/git-config.adoc
> 100644 blob 1af38f402ed6437353fb5765f62251966d828df9	Documentation/git-last-modified.adoc
> 100644 blob dce5c49ca2ba65fd6a2974e38f67134215bee369	refs.c
> 100644 blob 46a6008e07f2624239139cd8b2ff712545f07d3f	refs.h
>
> $ git last-modified HEAD -- refs.c refs.h Documentation/git-last-modified.adoc Documentation/git-config.adoc
> 56073a0af90be947cfefbfc3cf762b268e5e20a9	Documentation
> 062b914c841329a003f74e1340ea5178391274a6	refs.c
> 47478802daddf3f9916111307f153c6298ffc0bc	refs.h
>
> I have to agree with Kristoffer here, and the latter is not what I
> would expect. Thanks for the testing! I will try to address in next
> version.

After some more testing and tinkering with the code, I've decided to
keep the behavior for several reasons:

1. While behavior differs from git-ls-tree(1) (see above), current
   behavior is identical to git-diff-tree(1):

   $ git diff-tree HEAD~1000 HEAD -- refs.c refs.h Documentation/git-last-modified.adoc Documentation/git-config.adoc
   :040000 040000 810861a07e1360d3e3fa00db3c0d01e0604ff27a 1b01b770c15e7ae586452bb3587c3ce7c01abd91 M	Documentation
   :100644 100644 55d2e0b2cb9e959443e98eb329fdf97eff9073a9 dce5c49ca2ba65fd6a2974e38f67134215bee369 M	refs.c
   :100644 100644 d278775e086bfa7990999c226ad1db2f488e890d 46a6008e07f2624239139cd8b2ff712545f07d3f M	refs.h

   Both git-diff-tree(1) and git-last-modified(1) are marked as plumbing
   commands, git-ls-tree(1) isn't. So I think that okay.

2. This command uses the diff machinery to walk the trees, so it's not
   straightforward to change behavior.

3. We can later introduce `--max-depth` as Peff has been trying to do in
   the past, but that can happen outside this patch series. These has
   been taken out in an previous attempt[1] to upsteam the
   git-blame-tree(1) subcommand.
   Having option `--max-depth` would allow users to get all tree entries
   in for example the documentation directory, while not getting any
   from it's subtrees.

With these considerations I've submitted[2] a new version of my patches.

[1]: https://lore.kernel.org/git/patch-1.1-0ea849d900b-20230205T204104Z-avarab@gmail.com/
[2]: https://lore.kernel.org/git/20250709152628.1644521-1-toon@iotcl.com/

-- 
Cheers,
Toon