Re: [PATCH 2/2] diffcore-pickaxe doc: document -S and -G properly

From: Junio C Hamano <gitster@pobox.com>
Date: May 19, 2013, 07:33 UTC
Message-ID: <7vsj1jzao7.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vfvxlw055.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 12 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
> ...
>>  -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 ;-)

Show 28 quoted lines

>> -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.