Junio C Hamano [off-list ref] writes:
Ramkumar Ramachandra [off-list ref] writes:
...
quoted
-G<regex>::
- Look for differences whose added or removed line matches
- the given <regex>.
+ Grep through the patch text of commits for added/removed lines
+ that match <regex>. `--pickaxe-regex` is implied in this
+ mode.
The same comment on differences vs commits apply to this.
...
it will _not_ apply to users of -G.
s/.$/ unless they say --pickaxe-regex./; so -G does not imply it at
all.
"grep through", if the reader knows "grep", with "match <regex>", it
is crystal clear that this expects a regular expression. And that
is the only thing that makes -G and --pickaxe-regex superficially
related.
s/^The description begins with /; Sorry, but I couldn't write
complete sentences on a bus ;-)
quoted
-This transformation is used to find filepairs that represent
-changes that touch a specified string, and is controlled by the
--S option and the `--pickaxe-all` option to the 'git diff-*'
-commands.
-
-When diffcore-pickaxe is in use, it checks if there are
-filepairs whose "result" side and whose "origin" side have
-different number of specified string. Such a filepair represents
-"the string appeared in this changeset". It also checks for the
-opposite case that loses the specified string.
-
-When `--pickaxe-all` is not in effect, diffcore-pickaxe leaves
-only such filepairs that touch the specified string in its
-output. When `--pickaxe-all` is used, diffcore-pickaxe leaves all
-filepairs intact if there is such a filepair, or makes the
-output empty otherwise. The latter behaviour is designed to
-make reviewing of the changes in the context of the whole
-changeset easier.
This part is impossible to review on a bus, so I won't comment in
this message.
Why did you even have to touch the paragraph for --pickaxe-all?
That applies to both -S and -G. I thought it would be just the
matter of slightly tweaking the introductory paragraph (which was
written back when there was only -S), keeping the second paragraph
for -S as-is, and insert an additional paragraph for -G before
--pickaxe-all.
Now I see that the paragraph for --pickaxe-all needs to be touched;
the original talks about "touch the specified string", which only
applies to -S and needs to be adjusted.
So here is my attempt of clarifying it.
This transformation is used to find filepairs that represent
two kinds of changes, and is controlled by the -S, -G and
--pickaxe-all options.
The "-S<block of text>" option tells Git to consider that a
filepair has differences only if the number of occurrences
of the specified block of text is different between its
preimage and its postimage, and treat other filepairs as if
they did not have any change. This is meant to be used with
a block of text that is unique enough to occur only once (so
expected the number of occurences is 1 vs 0 or 0 vs 1) to
use with "git log" to find a commit that touched the block
of text the last time. When used with the "--pickaxe-regex"
option, the <block of text> is used as a POSIX extended
regular expression to match, instead of a literal string.
The "-G<regular expression>" option tells Git to consider
that a filepair has differences only if a textual diff
between its preimage and postimage would indicate a line
that matches the given regular expression is changed, and
treat other filepairs as if they did not have any change.
When -S or -G option is used without "--pickaxe-all" option,
only filepairs that match their respective criterion are
kept in the output. When `--pickaxe-all` is used, all
filepairs intact if there is such a filepair, or makes the
output empty otherwise. This behaviour is designed to make
reviewing of the changes in the context of the whole
changeset easier.
Junio C Hamano wrote:
[...]
I agree with the other comments, and have made suitable changes.
Let's review your block now.
This transformation is used to find filepairs that represent
two kinds of changes, and is controlled by the -S, -G and
--pickaxe-all options.
Why do you call this a "transformation"? Is git log --author="foo" a
transformation on the git-log output? Then how is git log -Sfoo a
transformation?
Two kinds of changes controlled by three different options? Isn't the
original much clearer?
The title says diffcore-pickaxe, and the first paragraph says:
There are two kinds of pickaxe: the S kind (corresponding to 'git log
-S') and the G kind (mnemonic: grep; corresponding to 'git log -G').
The "-S<block of text>" option tells Git to consider that a
filepair has differences only if the number of occurrences
of the specified block of text is different between its
preimage and its postimage, and treat other filepairs as if
they did not have any change.
I'll rewrite this without the trailing "and treat other filepairs as
if they did not have any change" (which I'm not fond of).
This is meant to be used with
a block of text that is unique enough to occur only once (so
expected the number of occurences is 1 vs 0 or 0 vs 1) to
use with "git log" to find a commit that touched the block
of text the last time.
You're saying how you think it's "meant" to be used, but in doing so
you've failed to describe its operation faithfully. I've already
described how it's meant to be used in diff-options (digging a block
of text iteratively) and this is the place to explain what it is doing
faithfully. Hence my previous writeup on changes in number of
occurrences and rename detection: I _had_ to read the code to
understand it properly, and your writeup is not helping by telling me
about idiomatic usage.
Also, you've dropped computational expense which was there in the original.
When used with the "--pickaxe-regex"
option, the <block of text> is used as a POSIX extended
regular expression to match, instead of a literal string.
Better.
The "-G<regular expression>" option tells Git to consider
that a filepair has differences only if a textual diff
between its preimage and postimage would indicate a line
that matches the given regular expression is changed, and
treat other filepairs as if they did not have any change.
"would indicate"? Really? I'll rewrite this without the trailing
"and treat other filepairs ..".
You've once again dropped what it means in the context of in-file
moves (rename detection), and computational expense from the original.
When -S or -G option is used without "--pickaxe-all" option,
only filepairs that match their respective criterion are
kept in the output.
Much better.
When `--pickaxe-all` is used, all
filepairs intact if there is such a filepair, or makes the
output empty otherwise.
-ENOPARSE. I didn't particularly like the original, and this isn't
better. I'll rewrite it.
This behaviour is designed to make
reviewing of the changes in the context of the whole
changeset easier.
Same as original. Okay.
Thanks.
On Fri, May 24, 2013 at 5:37 AM, Ramkumar Ramachandra
[off-list ref] wrote:
Junio C Hamano wrote:
quoted
[...]
I agree with the other comments, and have made suitable changes.
Let's review your block now.
quoted
This transformation is used to find filepairs that represent
two kinds of changes, and is controlled by the -S, -G and
--pickaxe-all options.
Why do you call this a "transformation"? Is git log --author="foo" a
transformation on the git-log output? Then how is git log -Sfoo a
transformation?
Two kinds of changes controlled by three different options? Isn't the
original much clearer?
They are all three filters. They transform the output by limiting it
to commits which meet specific conditions. Transformation is used in
the network-graphs sense of the word. It fits the beginning of the
document where it says this:
The diffcore mechanism is fed a list of such comparison results
(each of which is called "filepair", although at this point each
of them talks about a single file), and transforms such a list
into another list. There are currently 5 such transformations:
- diffcore-break
- diffcore-rename
- diffcore-merge-broken
- diffcore-pickaxe
- diffcore-order