Re: [PATCH] precious-files.txt: new document proposing new precious file type

[Elijah Newren <newren@gmail.com>]

On Tue, Dec 26, 2023 at 9:28 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Elijah Newren <newren@gmail.com>
> >
> > 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.