On Tue, Oct 10, 2023 at 10:07:08AM -0700, Junio C Hamano wrote: > Josh Triplett <josh@xxxxxxxxxxxxxxxx> writes: > > > While I'd love for it to default to that and require an extra option to > > clean away precious files, I'd expect that that would break people's > > workflows and finger memory. If someone expects `git clean -x -d -f` to > > clean away everything, including `.config`, and then it leaves some > > files in place, that seems likely to cause problems. (Leaving aside that > > it might break scripted workflows.) > > I thought the point of introducing the new "precious" class of > paths, in addition to the current "tracked", "ignored, untracked, > and expendable", "not ignored and untracked", is so that people can > do "git clean -x -d -f" and expect the ".config" that is marked as > "precious" to stay. Before their Git learned the precious class, if > they marked ".config" as "ignored, untracked, and expendable", then > such an invocation of "clean" would have removed it, but if they add > it to the new "precious" class, their expectation ought to be that > precious ones are not removed, no? Otherwise I am not quite sure > what the point of adding such a new protection is. I'd expect a lot of projects to move things *from* the current "ignored" state to "precious", once "precious" exists. Linux `.config`, for instance. That said, I do agree that the ideal behavior is for clean to preserve precious files by default, and require an extra option to remove precious files. If you think that doesn't have backwards-compatibility considerations, then it certainly seems much easier to jump directly to that behavior. - Josh Triplett