Re: [RFC PATCH] Introduce "precious" file concept

From: Per Lundberg <per.lundberg@hibox.tv>
Date: Nov 26, 2018, 09:30 UTC
Message-ID: <280aa9c3-0b67-c992-1a79-fc87bbc74906@hibox.tv>
In-Reply-To: <20181112232209.GK890086@genre.crustytoothpaste.net>

On 11/13/18 1:22 AM, brian m. carlson wrote:

Show 9 quoted lines

> This is going to totally hose automation.  My last job had files which
> might move from tracked to untracked (a file that had become generated),
> and long-running CI and build systems would need to be able to check out
> one status and switch to the other.  Your proposed change will prevent
> those systems from working, whereas they previously did.
> 
> I agree that your proposal would have been a better design originally,
> but breaking the way automated systems currently work is probably going
> to be a dealbreaker.

How about something like this:

1. Introduce a concept with "garbage" files, which git is "permitted to 
delete" without prompting.

2. Retain the current default, i.e. "ignored files are garbage" for now, 
making the new behavior _opt in_ to avoid breaking automated 
systems/existing scripts for anyone. Put the setting for this behind a 
new core.* config flag.

3. In the plan for version 3.0 (a new major version where some breakage 
can be tolerable, according to Semantic Versioning), change the default 
so that "only explicit garbage is garbage". Include very clear notices 
of this in the release notes. The config flag is retained, but its 
default changes from true->false or vice versa. People who dislike the 
new behavior can easily change back to the 2.x semantics.

Would this be a reasonable compromise for everybody?

-- 
Per Lundberg