On Mon, Oct 8, 2018 at 8:22 PM Jeff King <peff@xxxxxxxx> wrote: > > On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote: > > > Julia Lawall <julia.lawall@xxxxxxx> writes: > > > > >> Doing the same for -S is much harder at the machinery level, as it > > >> performs its thing without internally running "diff" twice, but just > > >> counts the number of occurrences of 'foo'---that is sufficient for > > >> its intended use, and more efficient. > > > > > > There is still the question of whether the number of occurrences of foo > > > decreases or increases. > > > > Hmph, taking the changes that makes the number of hits decrease > > would catch a subset of "changes that removes 'foo' only---I am not > > interested in the ones that adds 'foo'". It will avoid getting > > confused by a change that moves an existing 'foo' to another place > > in the same file (as the number of hits does not change), but at the > > same time, it will miss a change that genuinely removes an existing > > 'foo' and happens to add a 'foo' at a different place in the same > > file that is unrelated to the original 'foo'. Depending on the > > definition of "I am only interested in removed ones", that may or > > may not be acceptable. > > I think that is the best we could do for "-S", though, which is > inherently about counting hits. > > For "-G", we are literally grepping the diff. It does not seem > unreasonable to add the ability to grep only "-" or "+" lines, and the > interface for that should be pretty straightforward (a tri-state flag to > look in remove, added, or both lines). > > -Peff Yea. I know I've wanted something like this in the past. Thanks, Jake
