From: Junio C Hamano <gitster@pobox•com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail•com>
Cc: git@vger•kernel.org, Jonathan Nieder <jrnieder@gmail•com>
Subject: Re: [PATCH WIP 0/3] git log --exclude
Date: Fri, 07 Oct 2011 10:57:45 -0700 [thread overview]
Message-ID: <7vaa9cwup2.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CACsJy8DJs_cmCZegyPk=tB-bxWp4izrsTn8T=xeV1sU4fS5oTQ@mail.gmail.com> (Nguyen Thai Ngoc Duy's message of "Fri, 7 Oct 2011 18:16:04 +1100")
Nguyen Thai Ngoc Duy <pclouds@gmail•com> writes:
> There may be a solution to mix depth limit and negative pathspec. I
> haven't thought carefully about that because I lean towards a simpler
> behaviour that only allows one negation level: a file is in if it
> matches any positive pathspecs and none of negative ones.
I tend to think it probably is acceptable solution to define "struct
pathspec" to have one positive and one negative set, traversing and
declaring a match on what matches something from the positive set only if
it does not match anything in the negative set.
That is similar to how we define revision ranges in the sense that the
range notation to have two ranges (A..B C..D) does not mean union of two
sets (A..B + C..D), but is difference between two unions ((B D)-(A C)).
> This is enough if narrow clones consist of positive pathspec only. I
> really doubt if users would want to make a narrow clone that "contains
> A but not A/B, storage-wise".
And if you define "struct pathspec" to have one positive and one negative
set, you do not have to limit narrow clone only to positive. The repository
specific narrow pathspec will have one such "struct pathspec", but the
user may give us from the command line another "struct pathspec". At
runtime, we would merge them to form into one negative and one positive
set, and apply the same rule: nothing that matches any negative will
appear in the traversal or in the output.
prev parent reply other threads:[~2011-10-07 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 7:18 [PATCH WIP 0/3] git log --exclude Nguyễn Thái Ngọc Duy
2011-10-05 7:18 ` [PATCH WIP 1/3] diff-no-index: rename read_directory to avoid conflict from dir.h Nguyễn Thái Ngọc Duy
2011-10-05 7:18 ` [PATCH WIP 2/3] tree-diff: teach it to understand exclude patterns Nguyễn Thái Ngọc Duy
2011-10-05 7:18 ` [PATCH WIP 3/3] log: add --exclude option Nguyễn Thái Ngọc Duy
2011-10-05 8:08 ` [PATCH WIP 0/3] git log --exclude Matthieu Moy
2011-10-05 8:28 ` Nguyen Thai Ngoc Duy
2011-10-05 17:20 ` Junio C Hamano
2011-10-06 14:34 ` Jeff King
2011-10-06 17:22 ` Junio C Hamano
2011-10-06 21:47 ` Nguyen Thai Ngoc Duy
2011-10-07 7:16 ` Nguyen Thai Ngoc Duy
2011-10-07 17:57 ` 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=7vaa9cwup2.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jrnieder@gmail$(echo .)com \
--cc=pclouds@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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