On Sun, 2 Feb 2020 at 21:47, Adam Dinwoodie <adam@xxxxxxxxxxxxx> wrote: > On Sunday 02 February 2020 at 08:45 pm +0100, Martin Ågren wrote: > > On Sun, 2 Feb 2020 at 20:24, Adam Dinwoodie <adam@xxxxxxxxxxxxx> wrote: > > Ah, thank you! I had completely misread what these examples were trying > to achieve. I think your example (or indeed anything from a different > domain) would have avoided me getting confused in the first place. > Although I'm much less fussed now I realise the problem here was > entirely my understanding rather than an error in the docs. > > > BTW, I wonder what "in the same file" tries to say -- my hunch is we > > could drop those words without any loss of correctness or readability. > > Would you agree? > > I think "in the same file" is meaningful here: as I understand it both > forms would find a commit that removed a line from one file and added it > back to a _different_ file, but only the -G form would pick it when > removed and added lines are in the same file. You're right, it is needed. At least the way the example is given now, where there's some arbitrary amount of left-out context between the "+" and the "-" line, it's necessary to limit that by saying that it's in the same file. Because this is an example, we're allowed to make it as concrete as we see fit. For example: To illustrate the difference between `-S<regex> --pickaxe-regex` and `-G<regex>`, consider a commit with the following diff: + ---- - hit = !frotz(nitfol, mf2.ptr, 1, 0); + return !frotz(nitfol, two->ptr, 1, 0); ---- + While `git log -G"frotz\(nitfol"` will show this commit, `git log -S"frotz\(nitfol" --pickaxe-regex` will not (because the number of occurrences of that string did not change). Or does that make it too specific, i.e., could this give readers the wrong impression that -G and/or -S and/or the difference explained here only apply to such "trivial" cases? Martin