On Tue, Dec 26, 2023 at 9:28 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: Elijah Newren <newren@xxxxxxxxx> > > > > We have traditionally considered all ignored files to be expendable, but > > users occasionally want ignored files that are not considered > > expendable. Add a design document covering how to split ignored files > > into two types: 'trashable' (what all ignored files are currently > > considered) and 'precious' (the new type of ignored file). > > The proposed syntax is a bit different from what I personally prefer > (which is Phillip's [P14] or something like it), but I consider that > the more valuable parts of this document is about how various > commands ought to interact with precious paths, which shouldn't > change regardless of the syntax. I agree that syntax and command behavior are mostly separate issues, but unfortunately they are not orthogonal. In particular, syntax of precious file specification is directly tied to fallback behavior for older Git clients, and it might potentially affect backward compatibility of non-cone-mode sparse-checkout syntax as well. I think fallback behavior is of particular importance. There are precisely two choices in our design for how older Git versions can treat precious files: * ignored-and-expendable * untracked-and-precious If we pick syntax that causes older Git versions to treat precious files as ignored-and-expendable, we risk deleting important files. Alternatively, if we pick syntax that causes older Git versions to treat precious files as untracked-and-precious, they won't be ignored by e.g. git-status, and are easier to accidentally add with git-add. I felt the "precious" bit was much more important than the "ignored" bit of "precious" files, so I thought untracked-and-precious was a better fallback. However, to get that, we have to rule out lots of the syntax proposals, such as Phillip's [P14]. Anyway, I'm open to alternative syntax, but we need to measure it against the relevant criteria, which I believe are: (A) ease for users to understand, remember, and use (B) size of backward compatibility break with .gitignore syntax (C) appropriateness of implied fallback behavior for older Git clients with precious files (D) room for additional extension in .gitignore files (E) potential affects on backward compatibility of non-cone sparse-checkout syntax We probably also need to agree on the relative importance of these criteria; personally, I would probably order them from most important to least as C, B, E, A, D. Phillip's P14 is better for D, and perhaps a little better for B, but I thought slightly worse for A, and much worse for C. (I think there's no significant relative difference for E between his proposed syntax and mine.) > Thanks for putting this together.
