On Thu, Nov 24 2022, Zack Weinberg wrote: > On Thu, Nov 24, 2022, at 5:31 AM, Phillip Wood wrote: > [...] >> I'm afraid I'm not >> familiar with the --follow code so I've no idea how to fix this. > > I'm honestly unsure what the right behavior _should_ be, now. I > expected --grep to be applied very late in the process, after the > set of commits touching the specified file had already been computed > (including all of its previous names, because of --follow) but the > documentation is ambiguous. This doesn't help with your case, but I remember there being some similar confusions and/or expectations mismatches reported in the patch. E.g. "--since" here: https://lore.kernel.org/git/220401.86pmm1nmvh.gmgdl@xxxxxxxxxxxxxxxxxxx/ I couldn't find a reference quickly, but I seem to recall (but perhaps I'm imagining it) that we had a report/discussion semi-recently about: git log --reverse --follow -- path Which has a similar edge case, e.g. try on git.git: git log --reverse --follow -- object-name.c That's also "correct" if you look at it from the POV of how we implement it, i.e. we'll traverse, and the rename to object-name.c is the first time we encounter the name from the POV of the walking logic. Hrm, but shouldn't we show all commits *after* the rename then? Anyway, I haven't thought about it this time around, just wanted to provide some rabbit-hole references in case you're interested. In terms of optimization it's *very* useful that we take these shortcuts, but as your (and some of these) examples show it can yield the wrong or unexpected result in some cases, and in those cases we usually have no non-brute-force way of getting the "right" (or "desired") result other (brute force being: parse "git log -p" yourself). So it would be nice in general if we had some ability to say what filters apply at what stage in the walk, but I suspect that would require a rather large UX overhaul...
