All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Stefan Beller <sbeller@google.com>, git@vger.kernel.org, peff@peff.net
Subject: Re: [PATCH] diffcore: add a filter to find a specific blob
Date: Thu, 14 Dec 2017 14:44:37 -0800	[thread overview]
Message-ID: <xmqqefnxrktm.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20171214212234.GC32842@aiede.mtv.corp.google.com> (Jonathan Nieder's message of "Thu, 14 Dec 2017 13:22:34 -0800")

Jonathan Nieder <jrnieder@gmail.com> writes:

> Putting it in context, we have:
>
> 	pickaxe options:
> 	-S: detect changes in occurence count of a string
> 	-G: grep lines in diff for a string
>
> 	--pickaxe-all:
> 		do not filter the diff when the patch matches pickaxe
> 		conditions.
>
> 		kind of like log --full-diff, but restricted to pickaxe
> 		options.
> 	--pickaxe-regex: treat -S argument as a regex, not a string
>
> Is this another kind of pickaxe option?  It feels similar to -S, but
> at an object level instead of a substring level, so in a way it would
> be appealing to call it --pickaxe-object.  Does --pickaxe-all affect
> it like it affects -S and -G?

It does feel quite close to -S, but is slightly different.

Instead of spelling out the exact contents to pass as the argument
to the -S option, you are giving a blob object name instead.

However, if you rename path F to G without any modification, or if
you flip only the mode bits, -S would reject such a filepair, as
both sides have the same number of the sought-after string, I think.
Unlike -S, this new thing should show such a filepair because it is
designed to show any filepair with either (or both) side has the
sought-after object.

We could make this identical to -S, i.e. only when a filepair has
sought-after object on either (or both) sides *and* its pre and post
image sides do not talk about the same object.

    Note.  I am phrasing the above awkwardly because we can ask for
    more than one object, and a filepair that changes a path from
    object A to object B, both of which are what we are looking for,
    want to be caught.  If I phrased the above as "only when only
    one side of a filepair has an object we are looking for and the
    other side does not", such a filepair would not be shown.

I have a suspicion that such a change may be worthwhile.

> Another context to put it in is:
>
> 	--diff-filter:
> 		limit paths (but not commits?) to those with a change
> 		matching optarg

IIUC, this is applied at the output phase after all of the rename,
pickaxe etc. are done (e.g. "Now you have the diff to give me, show
me only the additions in it").  It is a poor match for this new
thing, as "Now you have the diff to give me, show me only the ones
that involve these blobs" does not sound all that useful.




      parent reply	other threads:[~2017-12-14 22:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08  0:24 [PATCH 0/1] diffcore-blobfind Stefan Beller
2017-12-08  0:24 ` [PATCH 1/1] diffcore: add a filter to find a specific blob Stefan Beller
2017-12-08  9:34   ` Jeff King
2017-12-08 16:28     ` Ramsay Jones
2017-12-08 20:19       ` Jeff King
2017-12-08 20:39         ` Stefan Beller
2017-12-08 21:38           ` Jeff King
2017-12-08 15:04   ` Junio C Hamano
2017-12-08 17:21     ` Junio C Hamano
2017-12-08 21:11     ` Stefan Beller
2017-12-08 21:15       ` Junio C Hamano
2017-12-11 19:58 ` [PATCH 0/1] diff-core blobfind Stefan Beller
2017-12-11 19:58   ` [PATCH 1/1] diffcore: add a filter to find a specific blob Stefan Beller
2017-12-11 23:17     ` Junio C Hamano
2017-12-12  0:21       ` Stefan Beller
2017-12-12  1:24         ` [PATCH] " Stefan Beller
2017-12-12 18:36           ` Junio C Hamano
2017-12-14 21:22           ` Jonathan Nieder
2017-12-14 22:30             ` Stefan Beller
2017-12-14 22:52               ` Jonathan Nieder
2017-12-15  2:18                 ` Junio C Hamano
2017-12-27 18:49                   ` Stefan Beller
2017-12-27 18:59                     ` Jonathan Nieder
2017-12-27 19:57                       ` Junio C Hamano
2017-12-14 22:44             ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqefnxrktm.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.