From: Junio C Hamano <gitster@pobox•com>
To: Duy Nguyen <pclouds@gmail•com>
Cc: "Christian Couder" <christian.couder@gmail•com>,
"Matthieu Moy" <Matthieu.Moy@grenoble-inp•fr>,
"Toralf Förster" <toralf.foerster@gmx•de>,
"git@vger•kernel.org" <git@vger•kernel.org>
Subject: Re: RFC: git bisect should accept "paths-to-be-excluded"
Date: Tue, 17 Sep 2013 10:02:33 -0700 [thread overview]
Message-ID: <xmqqsix3z8ie.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACsJy8AEoUUat-1smJ1BmDuDBLseWf8oZ+EJyuadSLncb1UMSw@mail.gmail.com> (Duy Nguyen's message of "Tue, 17 Sep 2013 18:45:00 +0700")
Duy Nguyen <pclouds@gmail•com> writes:
> On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder
> <christian.couder@gmail•com> wrote:
>> On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp•fr> wrote:
>>> Christian Couder <christian.couder@gmail•com> writes:
>>>
>>>> In practice though, as git bisect is a kind of binary search, if what
>>>> you want to exclude is exclusively touched by half the commits, it
>>>> will only add one more bisection step if you don't exclude it.
>>>
>>> Actually, I think the same remark would apply to any other Git command
>>> that deal with a set of revisions. If you want to review code with "git
>>> log -p", but you don't care about a subdirectory, you may want a "git
>>> log -p --ignore-dir foo/" or so, too.
>>
>> Yeah, and there was a patch series about that 2 years ago:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/182830/
>
> And that's just one of the few attempts if I remember correctly. I
> guess it's time revisit it. A few things to sort out before we get to
> the implementation:
>
> Support flat or nested negation (i.e.include A, ignore A/B, but
> include A/B/C..). Nested thing complicates things so I'm towards the
> flat exclusion (exclude B means all inside B, no buts nor excepts) and
> probably cover most use cases
Yeah, it is easy to say that
git log -- A ':(exclude)A/B' A/B/C
has two positive (A, A/B/C) and one negative (A/B), and then the
most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is
included.
But to actually _design_ it, there are ambiguities that makes
understanding and explaining the semantics, especially given
pathspecs can have wildcards, icase matches, etc. For example, is
":(exclude,icase)A/B/?" more specific than "A/?/C" or less?
So I tend to agree that we should aim for an easier to explain, if
less capable, approach.
> Interaction with "git grep --depth"
I am not sure how that affects anything. Conceptually, isn't
"--depth" an independent axis to filter out paths that have too many
components after given positive pathspec elements? E.g. given
git grep --depth=2 pattern -- A B/C
we will grab paths from two levels starting at A and B/C (so A/1/2
and B/C/1/2 may hit but not A/1/2/3 nor B/C/1/2/3). Shouldn't
negative pathspecs just filter that depth filtering, i.e. if you
have ":(exclude)*/1/*", even though both "A/1/2" and "A/a/b" may
pass the --depth=2 filter, the former is excluded while the latter
is not.
> Syntax. I guess --ignore (or --exclude) is more intuitive than
> ":(exclude)something" but then it might collide with existing options
> (I did not check if --ignore or --exclude is used anywhere though).
> The latter also enables combining with other filters, such as
> case-insensitive matching..
I do not think it is an option to do this with any mechanism other
than negative pathspecs.
next prev parent reply other threads:[~2013-09-17 17:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 12:39 RFC: git bisect should accept "paths-to-be-excluded" Toralf Förster
2013-09-17 7:26 ` Christian Couder
2013-09-17 8:21 ` Matthieu Moy
2013-09-17 9:03 ` Christian Couder
2013-09-17 11:45 ` Duy Nguyen
2013-09-17 17:02 ` Junio C Hamano [this message]
2013-09-17 18:12 ` Piotr Krukowiecki
2013-09-17 19:04 ` Junio C Hamano
2013-09-17 19:41 ` Piotr Krukowiecki
2013-09-17 20:47 ` Junio C Hamano
2013-09-18 2:22 ` Duy Nguyen
2013-11-20 1:41 ` [PATCH] Support pathspec magic :(exclude) and its short form :- Nguyễn Thái Ngọc Duy
2013-11-20 23:48 ` Junio C Hamano
2013-11-21 2:10 ` Duy Nguyen
2013-11-21 18:43 ` Junio C Hamano
2013-09-17 16:23 ` RFC: git bisect should accept "paths-to-be-excluded" Toralf Förster
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=xmqqsix3z8ie.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=Matthieu.Moy@grenoble-inp$(echo .)fr \
--cc=christian.couder@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=pclouds@gmail$(echo .)com \
--cc=toralf.foerster@gmx$(echo .)de \
/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