On Tue, Feb 15, 2022 at 5:07 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Elijah Newren <newren@xxxxxxxxx> 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.
