Re: [RFC] Define "precious" attribute and support it in `git clean`

[Sebastian Thiel <sebastian.thiel@icloud.com>]

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