On 12 Oct 2023, at 18:58, Junio C Hamano wrote:
> I presume you picked '$' > exactly because of this reason?
Yes, and because I thought '$' seems a great fit to represent value.
> I do not think it will be the end of the world if we don't do so,
> but it would be really really nice if we at least explored a way (or
> two) to make a big enough hole in the syntax to not just add
> "precious", but leave room to later add other traits, without having
> to worry about breaking the backward compatibility again. A
> simplest and suboptimal way may be to declare that a path that
> begins with '$' now needs '\'-quoting (just like your proposal),
> reserve '$$' as the precious prefix, and '$' followed by any other
> byte reserved for future use, but there may be better ideas.
Even though I'd love to go with the unextensible option assuming it would last
another 15 years, I can see the appeal of making it extensible from the start.
In a world where '$' is a prefix, I'd also think that it's now possible to
specify exclusion using '$!path' for completeness, if '$$path' marks 'path'
precious.
But if there is now a prefix, I feel that it might as well be chosen so that it
is easier to remember and/or less likely to cause conflicts. I think it must
have been that reason for pathspecs to choose ':' as their prefix, and it seems
to be an equally good choice here.
This would give us the following, taking the Linux kernel as example:
.*
!this-file-is-hidden-and-tracked
:!new-syntax-for-negation-for-completeness
\!an-ignored-file-with-leading-!
\:an-ignored-file-with-leading-:-which-is-technically-breaking
:$.config
:x-invalid-as-:-needs-either-!-or-$-to-follow-it
Now ':$path' would make any path precious, which is `:$.config` in the example
above.
How does that 'feel'? Is the similarity to pathspecs without being pathspecs
an anti-feature maybe?
>> Thus, to make this work, projects that ship the `.gitignore` files would *have
>> to add patterns* that make certain files precious.
>
> Not really. They do not have to do anything if they are content
> with the current Git ecosystem. And users who have precious stuff
> can mark them in the.git/info/excludes no?
Yes, but only if they control all the ignore patterns in their global files. If
the repository decides to exclude a file they deem precious, now it won't be
precious anymore as their ':$make-this-precious' pattern is seen sequentially
after the pattern in the repository.
For instance, tooling-specific ignores are typically fully controlled by the
user, like '/.idea/', which could now easily be made precious with ':$/idea/'.
But as the Linux kernel repository ships with a '.gitignore' file that includes
the '.*' pattern, users won't be able to 'get ahead' of that pattern with their
':$.config' specification.
> The only case that is
> problematic is when the project says 'foo' is ignored and expendable
> but the user thinks otherwise. So to make this work, projects that
> ship the ".gitignore" files have to avoid adding patterns to ignore
> things that it may reasonably be expected for its users to mark
> precious.
Yes, I think my paragraph above is exactly that but with examples to practice
the new syntax-proposal.
>
>> Such opted-in projects would produce `.gitignore` files like these:
>>
>> .*
>> $.config
>
> I would understand if you ignored "*~" or "*.o", but why ignore ".*"?
I don't have an answer, the example is from the Linux Kernel repository was
added in 1e65174a33784 [1].
I am definitely getting excited about the progress the syntax is making :),
thanks for proposing it!
[ Reference ]
1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e65174a33784
