Re: support comma-separated fetch specs list?

[Junio C Hamano <gitster@pobox.com>]

ryenus <ryenus@gmail.com> writes:

> Maybe the cause is also my ignorance or lack of carefulness to read the
> docs, but searching for "comma separated list" in Git manual would
> return hundreds of results:
> https://www.google.com/search?q=%22comma+separated%22+list+site%3Agit-scm.com
>
> So I guess it's fair to expect it to work in the fetch spec as well?

I doubt it.

The contents of these "comma separated list" are taken from a fixed
vocabulary and not from unbounded set of things the end-user can
freely come up with that allows a comma as part of values.

In other words, "--option=ours,theirs" may make sense only because
we control the vocabulary 'common', 'ours', and 'theirs', and we
make sure the vocabulary does not contain any word with comma in it.

When somebody adds a new option, we try hard during the review not
to allow "--option=thing1,thing2,thing3" as the syntax we give at
the UI level where thing$n are end-user controlled values, because
that would rob end-users from the option of having a comma in their
thing$n (for whatever reason).  Certain kind of things naturally do
not make sense to contain comma in them (e.g. list of numbers, for
example) and we may allow end-user controlled input as part of a
comma separated tuple, and when the tuple has a fixed length whose
size will never change, we may allow end-user controlled thing as
the last element of such a comma-separated tuple, but extending that
to refspec, pathspec, etc. is a bit of stretch, I would have to say.