git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] pickaxe: use textconv for -S counting

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 13, 2012, 23:13 UTC
Message-ID
<7vk3tpcd0w.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20121028124701.GB24548@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 7 quoted lines
> We currently just look at raw blob data when using "-S" to
> pickaxe. This is mostly historical, as pickaxe predates the
> textconv feature. If the user has bothered to define a
> textconv filter, it is more likely that their search string will be
> on the textconv output, as that is what they will see in the
> diff (and we do not even provide a mechanism for them to
> search for binary needles that contain NUL characters).
Oookay, I suppose...
Show 14 quoted lines
>  static int has_changes(struct diff_filepair *p, struct diff_options *o,
>  		       regex_t *regexp, kwset_t kws)
>  {
> +	struct userdiff_driver *textconv_one = get_textconv(p->one);
> +	struct userdiff_driver *textconv_two = get_textconv(p->two);
> +	mmfile_t mf1, mf2;
> +	int ret;
> +
>  	if (!o->pickaxe[0])
>  		return 0;
>  
> -	if (!DIFF_FILE_VALID(p->one)) {
> -		if (!DIFF_FILE_VALID(p->two))
> -			return 0; /* ignore unmerged */

What happened to this part that avoids showing nonsense for unmerged paths?

Show 9 quoted lines
> +	/*
> +	 * If we have an unmodified pair, we know that the count will be the
> +	 * same and don't even have to load the blobs. Unless textconv is in
> +	 * play, _and_ we are using two different textconv filters (e.g.,
> +	 * because a pair is an exact rename with different textconv attributes
> +	 * for each side, which might generate different content).
> +	 */
> +	if (textconv_one == textconv_two && diff_unmodified_pair(p))
> +		return 0;
I am not sure about this part that cares about the textconv.

Wouldn't the normal "git diff A B" skip the filepair that are unmodified in the first place at the object name level without even looking at the contents (see e.g. diff_flush_patch())?

Shouldn't this part of the code emulating that behaviour no matter what textconv filter(s) are configured for these paths?

Previous: Jeff KingNext: Jeff King
Message 6 of 24 in “crash on git diff-tree -Ganything <tree> for new files with textconv filter”
  1. Peter OberndorferOct 27, 2012
  2. Jeff KingOct 28, 2012
  3. 0/2 textconv support for "log -S"Jeff King, Oct 28, 2012
  4. 1/2 pickaxe: hoist empty needle checkJeff King, Oct 28, 2012
  5. 2/2 pickaxe: use textconv for -S countingJeff King, Oct 28, 2012
  6. Junio C HamanoNov 13, 2012
  7. Jeff KingNov 15, 2012
  8. Junio C HamanoNov 20, 2012
  9. Junio C HamanoNov 20, 2012
  10. Jeff KingNov 21, 2012
  11. Peter OberndorferOct 28, 2012
  12. Jeff KingOct 29, 2012
  13. Jeff KingOct 29, 2012
  14. Peter OberndorferOct 29, 2012
  15. Jeff KingOct 29, 2012
  16. Jeff KingOct 29, 2012
  17. Jeff KingOct 30, 2012
  18. Junio C HamanoOct 30, 2012
  19. Jeff KingOct 30, 2012
  20. Ramsay JonesNov 1, 2012
  21. Peter OberndorferNov 7, 2012
  22. Jeff KingNov 7, 2012
  23. Peter OberndorferJun 3, 2013
  24. Jeff KingJun 3, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.