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

From: Per Lundberg <per.lundberg@hibox.tv>
Date: Nov 27, 2018, 14:50 UTC
Message-ID: <56ffc52f-644c-2c1d-6a16-c1005b064385@hibox.tv>
In-Reply-To: <CA+P7+xri1=peNpEiZCE802HwCXhojyp2BDvOR+6BBSoRtsZyzA@mail.gmail.com>

On 11/27/18 2:55 PM, Jacob Keller wrote:

> Personally, I would rather err on the side which requires the least
> interaction from users to avoid silently clobbering an ignored file.
>

 > [...]

> 
> I don't like the idea of precious because it means people have to know
> and remember to opt in, and it's quite possible they will not do so
> until after they've lost real data.

I agree strongly with this personally; if we must choose between "might break automation" and "might delete non-garbage files", I would say the former is the lesser evil of the two.

But, if I had 10 000 000 servers set up using automated scripts that would break because of this, I might think differently. Quite likely so, in fact.

What are these automation scenarios _more specifically_? Junio or Brian, would you care to elaborate? Is it for build servers where you want "git clean -dfx" to always reset the working copy to a pristine state or are we talking about some other scenarios?

> I'd only have trashable apply in the case where it was implicit. i.e.
> git clean -fdx would still delete them, as this is an explicit
> operation that (hopefully?) users know will delete data.

This is one of the tougher calls, unfortunately.

If I was a user (which I am), and I was typing "git clean -dfx", what would I expect?

The help text (currently) states "-x   remove ignored files, too".

Would it be safe to assume that people would understand that "ignored _does not_ mean trashable when doing "git checkout some-ref" BUT it _does_ mean trashable in the "git clean -dfx" context"? I'm not so certain. It would be one of those perceived inconsistencies that would make people scream in anger because they _presumed_ that with the new "trashable" concept, "git clean -dfx" would no longer hit them in the leg.

And the other way around: if we change "git clean -dfx" to _not_ treat "ignored == trashable", it is likely to "hose automation" as it has been previously stated. People who might be using this syntax and _want_ it to remove ignored files would be upset, and rightfully so.

So in my POV, it's a tough decision between two, less-than-optimal alternatives.

But I would perhaps be able to live with the current semantics for "git clean -dfx" _as long as we update the help text_ so that "-x" indicates more clearly that non-trashable files can be deleted. It doesn't make things _worse_ than they currently are and if this is what it takes to get the trashable concept implemented and accepted by the community, it's a compromise I'd be willing to make. -- Per Lundberg