git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Albert Yale <surfingalbert@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH/RFC v4] grep: Add the option '--exclude'
Date: Tue, 14 Feb 2012 09:35:23 -0800	[thread overview]
Message-ID: <7vfwed8gis.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CACsJy8DhtjG6AhPkb0SEm4g6zhtmuRb5x+4+P3A6eS0+_7OQNw@mail.gmail.com> (Nguyen Thai Ngoc Duy's message of "Mon, 6 Feb 2012 22:16:59 +0700")

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> It makes me wonder, why not add match_pathspec_with_exclusion(const
> struct pathspec *include_ps, const struct pathspec *exclude_ps,...),
> use the new function in grep.c and revert struct pathspec back to
> original? The same can be applied to tree_entry_interesting() (i.e.
> add a new one that takes two pathspec sets, which supports exclusion)

Sorry, but I am the one to blame for this in:

 http://thread.gmane.org/gmane.comp.version-control.git/189455/focus=189486

> I think you may make less changes that way.

The arrangement to use two pathspecs certainly is simpler in the short
term, but I think it is a short-sighted hack that is wrong for two
reasons.

 - Doing it that way will not give you a solution where you only have to
   update the command line parsing of an existing command to stuff
   negative patterns to the pathspec structure you have been passing down
   to the existing codepath, and the command starts to understand negative
   patterns without any other change.  You introduce a new pathspec that
   holds negative patterns, and pass that along with the positive one you
   have been passing down in the existing codepath for all commands that
   need to understand pathspec (otherwise we will be back to a similar
   situation we were in before you started looking at pathspec where we
   had three different implementations giving different semantics---some
   command knows how to handle this kind of pathspec but some others do
   not).

 - Look at the fields in 'struct pathspec' and think about what those
   outside "items" list mean. The recursive and max_depth fields are about
   how the namespace is traversed [*1*], so if a codepath that used to
   know only about positive patterns learns to also care about negative
   ones, using different settings for these two fields in two separate
   'struct pathspec' does not make sense.  It is conceptually much cleaner
   to make 'struct pathspec' the data structure used by the updated logic
   to match paths to pathspec that can have positive and negative patterns.


[Footnote]

*1* The has_wildcard field is about optimizing the matching during the
traversal so it is a bit different.  Also it is our longer term goal to
get rid of the "raw" field (which does not work well to substring match
against the path when pathspec "magic" is involved), so we won't worry
about it in this discussion.

      reply	other threads:[~2012-02-14 17:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02 14:25 [PATCH/RFC v4] grep: Add the option '--exclude' Albert Yale
2012-02-02 14:35 ` Nguyen Thai Ngoc Duy
2012-02-02 14:41   ` Albert Yale
2012-02-06 15:16 ` Nguyen Thai Ngoc Duy
2012-02-14 17:35   ` 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=7vfwed8gis.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=surfingalbert@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).