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

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: Oct 13, 2023, 11:25 UTC
Message-ID: <ZSkpOc/dcGcrFQNU@ugly>
In-Reply-To: <xmqqttqvg4lw.fsf@gitster.g>

On Thu, Oct 12, 2023 at 09:58:19AM -0700, Junio C Hamano wrote:

Show 6 quoted lines

>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.
>

that would invariably make the syntax more verbose, for dubious gain.

that the extension we're deliberating now (again) was coming (in some form) was clear for quite a while, while i'm not aware of anything else that would semantically fit gitignore (*). "other traits" sounds awfully like scope creep, and would most likely fit gitattributes better.

anyway, such a hypothetical "breaking" change wouldn't have much impact, because versioned files aren't affected by gitignore. and for the misclassification to be actually harmful, the user would have to be unable to notice or correct it.

(*) this got me thinking about things that would fit, and i came up with a modification of the proposal: one might want to specify just *how* precious a file is (which i guess would translate to how many times the extra override option would have to be passed to git-clean). (**)

i guess a suitable syntax for that would be

   2>.config

note that even though using the dollar sign to denote "precious" is kind of intuitive, i'm not using it for two reasons: a) it's not "crazy" enough to use it at not quite the beginning of a file name (note that traditionally it isn't even special on windows), and b) the visual separation of the prefix isn't as good as with the "arrow-like" character.

(**) actually, one would probably want proper type tagging (e.g., config files vs. autotools-generated files (which do not belong into a repo, but do into a tar-ball)). that really does sound a lot like gitattributes, only that the files aren't versioned.

regards