On Thu, Oct 12, 2023 at 09:58:19AM -0700, Junio C Hamano wrote:
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
