git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/6] wildmatch part 2
Date: Thu, 04 Oct 2012 10:43:16 -0700	[thread overview]
Message-ID: <7vwqz6yvyj.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1349336392-1772-1-git-send-email-pclouds@gmail.com> ("Nguyễn	Thái Ngọc Duy"'s message of "Thu, 4 Oct 2012 14:39:46 +0700")

Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:

> On Thu, Oct 4, 2012 at 1:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Perhaps the wildmatch code may not be what we want X-<.
>
> When I imported wildmatch I was hoping to make minimum changes to it.
> But wildmatch is probably the only practical way to support "**" even
> if we later need to change it the way we want. Other options are base
> our work on top of compat/fnmatch.c, which is an #ifdef spaghetti
> mess, or write a new fnmatch()-compatible function. Both unattractive
> to me.
>
> Anyway, this is on top of nd/wildmatch, which makes "ab**cd" match
> full pathname.

I do not think we are in a hurry to push "**" support in before we
know what semantics we want to get out of it.  Pushing half-baked
"this is good enough at least to me for now" topics before they are
ready will cost the users in the longer term.

On the other hand, the three patches (2/3/4) in this series look
like a good improvement regardless of what kind of matching engine
we use.  I would have preferred to see them _before_ nd/wildmatch.

I do not agree with the reasoning behind [1/6] that changes

	union {
		char *pattern;
		strict git_attr *attr;
	} u;
	char is_macro;

to

	char *pattern;
	strict git_attr *attr;
	char is_macro;

by the way.

The union is much less about space saving but is more about the
nature of the usage; we use pattern or attr but not both at the same
time.  Even if the pattern becomes richer with later patches, that
does not change the fundamental premise that depending on the value
of "is_macro", either "attr" is used or "pattern" is used but they
won't be in effect at the same time.  The evolution of this should
go more like this, I think:

	union {
		struct {
			const char *string;
			int pattern_length;
			int prefix_literal_length;
			int flags;
		} pattern;
		struct git_attr *attr;
	} u;
	char is_macro;

Thanks.

  parent reply	other threads:[~2012-10-04 22:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02 23:20 What's cooking in git.git (Oct 2012, #01; Tue, 2) Junio C Hamano
2012-10-03 15:23 ` Nguyen Thai Ngoc Duy
2012-10-03 18:17   ` Junio C Hamano
2012-10-04  1:56     ` Nguyen Thai Ngoc Duy
2012-10-04  6:01       ` Junio C Hamano
2012-10-04  7:39         ` [PATCH 0/6] wildmatch part 2 Nguyễn Thái Ngọc Duy
2012-10-04  7:39           ` [PATCH 1/6] attr: remove the union in struct match_attr Nguyễn Thái Ngọc Duy
2012-10-04  7:39           ` [PATCH 2/6] attr: avoid strlen() on every match Nguyễn Thái Ngọc Duy
2012-10-04  7:39           ` [PATCH 3/6] attr: avoid searching for basename " Nguyễn Thái Ngọc Duy
2012-10-04  7:39           ` [PATCH 4/6] attr: more matching optimizations from .gitignore Nguyễn Thái Ngọc Duy
2012-10-04  7:39           ` [PATCH 5/6] gitignore: do not do basename match with patterns that have '**' Nguyễn Thái Ngọc Duy
2012-10-04 17:59             ` Junio C Hamano
2012-10-05  7:01             ` Johannes Sixt
2012-10-05 11:23               ` Nguyen Thai Ngoc Duy
2012-10-04  7:39           ` [PATCH 6/6] t3001: note about expected "**" behavior Nguyễn Thái Ngọc Duy
2012-10-04 18:04             ` Junio C Hamano
2012-10-04 17:43           ` Junio C Hamano [this message]
2012-10-04  9:34     ` What's cooking in git.git (Oct 2012, #01; Tue, 2) Michael Haggerty
2012-10-04 11:46       ` Nguyen Thai Ngoc Duy
2012-10-04 15:17         ` Michael Haggerty
2012-10-04 16:39       ` Junio C Hamano
2012-10-05 12:19         ` Andreas Schwab
2012-10-05 12:30           ` Matthieu Moy
2012-10-05 14:15             ` Andreas Schwab
2012-10-05 13:21         ` Nguyen Thai Ngoc Duy
2012-10-04  8:17 ` David Michael Barr
2012-10-04  8:30   ` fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)) Jonathan Nieder
2012-10-04 13:16     ` Stephen Bash
2012-10-04 16:30       ` Junio C Hamano
2012-10-04 16:27   ` What's cooking in git.git (Oct 2012, #01; Tue, 2) Junio C Hamano
2012-10-30 12:15 ` Florian Achleitner

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=7vwqz6yvyj.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).