Re: [PATCH 5/7] sparse-checkout: reject non-cone-mode patterns starting with a '#'

From: Elijah Newren <newren@gmail.com>
Date: Feb 16, 2022, 02:23 UTC
Message-ID: <CABPp-BFymV-bQVfT7u1phO1N8MHu03SfbVa6Q+CDKeJL21Fbwg@mail.gmail.com>
In-Reply-To: <xmqqr183y5yh.fsf@gitster.g>

On Tue, Feb 15, 2022 at 5:07 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 26 quoted lines

>
> Elijah Newren <newren@gmail.com> writes:
>
> > If this were the only special character case, I'd totally agree, but I
> > do worry a bit that escaping this particular case might lead users to
> > expect us to escape and fix other special characters from '*?[]!\'.
>
> Sorry, but I do not quite get why it is a problem.  I understand
> that the idea behind this "rejection" is that "#" is special only
> when it appears in files (as comment introducer) and must be
> prefixed with "\", right?
>
> Do any of the wildcard characters mean different things depending on
> where they appear?  Isn't '*' a wildcard to match 0-or-more-bytes
> whether it appears in files or on the command line, and need to
> prefixed with "\" to make it non-special regardless of where it is
> found?
>
> > If users have files with those characters and specify an argument with
> > one of those, are we to automatically escape them as well?  If we
> > don't escape the other characters but do escape '#', aren't we being
> > inconsistent?
>
> I do not quite get where you are seeing an inconsistency.  Do you
> mean that it is inconsistent that "# comment" is only allowed in
> files but not on the command line?

I don't understand what distinction you are trying to make between the file or the command line; for non-cone mode, all positional arguments to sparse-checkout {add,set} are taken as-is and inserted into the $GIT_DIR/info/sparse-checkout file directly.

I don't like just assuming that users are specifying paths rather than patterns, when non-cone mode is all about specifying patterns rather than paths; it just feels broken to me. However, since comments can never match anything and part of the point of the sparse-checkout command is so that users don't have to edit or look at the $GIT_DIR/info/sparse-checkout file, it seemed worth flagging.

With all the special characters in non-cone mode ('*?[]!#\') and the years of training we've given to users to edit $GITDIR/info/sparse-checkout directly, there's really not much we can check for; this was the only thing I could think of that seemed reasonable to flag in non-cone mode. However, it's really not all that important to me, so I'll just drop this patch.

>  If so, a way to make it
> consistent may be to allow "# comment" even from the command line
> ;-)

Yes, dropping this patch would keep things consistent, and continue allowing "# comment" from the command line (even if users are unlikely to ever look at said comment). I'll do that.