On Mon, Feb 24, 2025 at 11:31 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Sun, Feb 23, 2025 at 2:30 AM Devste Devste <devstemail@xxxxxxxxx> wrote: [snip] > > Funnily enough, when I have a merge commit that contains only that 1 > > excluded file, it's the same behavior. > > > > 1) if there's only a single file in a commit, why does --find-renames > > cause a slowdown? There's nothing that could have been renamed in that > > case (probably the same for --find-copies) > > I'm not sure what this has to do with the above; you seem to have > switched tracks. If you have a commit whose toplevel tree has exactly > 1 file, and you're diffing it against some other commit with an > unspecified number of files, [snip] I'm only mentioning this in the vein of Elijah's requests for clarification: the wording "only a single file in a commit" is something I often see from newcomers who don't yet understand that a commit points to a tree of the entire repo, but the diff between a commit and it's parent might show only one modified file. (Sometimes I think we experts encourage this when we refer to that diff as the commit [1], [2].) Now, Devste's posted commands indicate they may have more Git experience and didn't fall to this trap, so Elijah's interpretation of "a commit whose toplevel tree has exactly 1 file" is perfectly reasonable—but we'd probably all like to know a bit more to confirm. I originally read "if there's only a single file in the commit" (with my newcomer lenses on) as "if I only changed one file before commiting." This is also partly based on a (mis)read of "a merge commit that contains only that 1 excluded file" (perhaps OP meant "modified"). [1]: https://jvns.ca/blog/2023/11/01/confusing-git-terminology/#commit [2]: https://jvns.ca/blog/2024/01/05/do-we-think-of-git-commits-as-diffs--snapshots--or-histories/ -- D. Ben Knoble
