On 11/13/18 1:22 AM, brian m. carlson wrote: > 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
