git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Nguyen Thai Ngoc Duy <pclouds@gmail.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)
Date: Thu, 04 Oct 2012 09:39:02 -0700	[thread overview]
Message-ID: <7vobki19ax.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <506D5837.6020708@alum.mit.edu> (Michael Haggerty's message of "Thu, 04 Oct 2012 11:34:47 +0200")

Michael Haggerty <mhagger@alum.mit.edu> writes:

> On 10/03/2012 08:17 PM, Junio C Hamano wrote:
>> 
>> What is the semantics of ** in the first place?  Is it described to
>> a reasonable level of detail in the documentation updates?  For
>> example does "**foo" match "afoo", "a/b/foo", "a/bfoo", "a/foo/b",
>> "a/bfoo/c"?  Does "x**y" match "xy", "xay", "xa/by", "x/a/y"?
>> 
>> I am guessing that the only sensible definition is that "**"
>> requires anything that comes before it (if exists) is at a proper
>> hierarchy boundary, and anything matches it is also at a proper
>> hierarchy boundary, so "x**y" matches "x/a/y" and not "xy", "xay",
>> nor "xa/by" in the above example.  If "x**y" can match "xy" or "xay"
>> (or "**foo" can match "afoo"), it would be unreasonable to say it
>> implies the pattern is anchored at any level, no?
>
> Given that there is no obvious interpretation for what a construct like
> "x**y" would mean, and many plausible guesses (most of which sound
> rather useless), I suggest that we forbid it.  This will make the
> feature easier to explain and make .gitignore files that use it easier
> to understand.
>
> I think that 98% of the usefulness of "**" would be in constructs where
> it replaces a proper part of the pathname, like "**/SOMETHING" or
> "SOMETHING/**/SOMETHING"...

I think it is a good way to go in the longer term, if we all agree
that "**" matching anything does not give us a useful semantics
[*1*].

Is it something we can easily get by simple patch into the wildmatch
code?  I'd hate to see us parsing the input and validating it before
passing it to the library, as we will surely botch the quoting or
something while doing so.

When we require "x/**/y", I think we still want it to match "x/y".
Do people agree, or are there good reasons to require at least one
level between x and y for such a pattern?  Assuming that we do want
to match "x/y" with "x/**/y", I suspect that "'**' matches anything
including a slash" would not give us that semantics. Is it something
we can easily fix in the wildmatch code?


[Footnote]

*1* The message you are responding to was written in a somewhat
provocative way on purpose so that people who like the way rsync
matches "**" can vocally object. I would like to see arguments from
the both sides to see if it makes sense.

  parent reply	other threads:[~2012-10-04 22:11 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           ` [PATCH 0/6] wildmatch part 2 Junio C Hamano
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 [this message]
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=7vobki19ax.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --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).