Thread (4 messages) 4 messages, 3 authors, 2023-10-29

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

From: Elijah Newren <hidden>
Date: 2023-10-29 06:44:18

Hi Sebastian,

On Mon, Oct 23, 2023 at 12:15 AM Sebastian Thiel
[off-list ref] wrote:
On 16 Oct 2023, at 8:02, Sebastian Thiel wrote:
quoted
I don't know if this time will be different as I can only offer to implement
the syntax adjustment, whatever that might be (possibly after validating
the candidate against a corpus of repositories), along with the update
to `git clean` so it leaves precious files alone by default and a new flag
to also remove precious files.
I am happy to announce this feature can now be contributed in full by me once
you give it a go. This would mean that the entirety of `git` would become
aware of precious files over time.

To my mind, and probably out of ignorance, it seems that once the syntax is
decided on it's possible for the implementation to start. From there I could
use Elijah's analysis to know which parts of git to make aware of precious files
in addition to `git clean`.

I am definitely looking forward to hearing from you :).
So, we typically don't pre-approve patches/features.  Junio described
this recently at [1].

However, starting things out with an RFC, as you've done, is certainly
a good first step to gauge whether folks think a feature is useful.

Occasionally, when the feature is bigger or touches lots of areas of
the code, people will even write up a design document, and first get a
review on the document, which then streamlines later reviews since we
have some of the high-level aspects agreed to.  Some examples:
  * Documentation/technical/hash-function-transition.txt
  * Documentation/technical/sparse-checkout.txt
  * Documentation/technical/sparse-index.txt
Each of which are in various stages between "these are ideas we think
are good and our plans to get there" to "most of this document has
since been implemented".  There are others in that directory too,
though not everything in that directory is a planning document; some
of the files are simply documentation of what already exists.

Anyway, creating a similar planning document and covering the various
cases I mentioned would likely be a very useful next step here.  I did
note that multiple ideas have been presented in this thread about the
syntax for specifying precious files, and it'd be good to nail one
down.  It would also be nice to see proposed answers to the several
cases I brought up (some of which Junio answered, others of which I
also have potential answers for so I could potentially help you craft
this document, and a few others that someone else would need to fill
in).  Sometimes we also want to cover pros/cons of the approaches we
have decided upon, in part because others may come along later and if
they discover a new pro or con that we haven't thought of, then we may
need to rethink the plan.

Hope that helps,
Elijah

[1] https://lore.kernel.org/git/xmqq8r9ommyt.fsf@gitster.g/ (local)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help