Re: git log -S or -G

4 messages, 4 authors, 2018-10-09 · open the first message on its own page

Re: git log -S or -G

From: Junio C Hamano <hidden>
Date: 2018-10-08 23:09:38

Julia Lawall [off-list ref] writes:
quoted
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.


Re: git log -S or -G

From: Jeff King <hidden>
Date: 2018-10-09 03:21:28

On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
Julia Lawall [off-list ref] writes:
quoted
quoted
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

Re: git log -S or -G

From: Jacob Keller <hidden>
Date: 2018-10-09 03:59:11

On Mon, Oct 8, 2018 at 8:22 PM Jeff King [off-list ref] wrote:
On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
quoted
Julia Lawall [off-list ref] writes:
quoted
quoted
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

Re: git log -S or -G

From: Julia Lawall <hidden>
Date: 2018-10-09 06:39:21


On Mon, 8 Oct 2018, Jacob Keller wrote:
On Mon, Oct 8, 2018 at 8:22 PM Jeff King [off-list ref] wrote:
quoted
On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
quoted
Julia Lawall [off-list ref] writes:
quoted
quoted
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.
It could also be nice to be able to specify multiple patterns, with and
and or between them.  So -A&-B would be remove A somewhere and remove B
somewhere.

julia
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help