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

On Mon, Nov 26, 2018 at 4:34 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

On Mon, Nov 26 2018, Duy Nguyen wrote:

quoted

On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg [off-list ref] wrote:

quoted

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

quoted

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.

How does this garbage thing interact with "git clean -x"? My
interpretation of this flag/attribute is that at version 3.0 by
default all ignored files are _not_ garbage, so "git clean -x" should
not remove any of them. Which is weird because most of ignored files
are like *.o that should be removed.

I also need to mark "precious" on untracked or even tracked files (*).
Not sure how this "garbage" attribute interacts with that.

(*) I was hoping I could get the idea [1] implemented in somewhat good
shape before presenting here. But I'm a bit slow on that front. So
yeah this "precious" on untracked/tracked thingy may be even
irrelevant if the patch series will be rejected.

I think a garbage (or trashable) flag, if implemented, wouldn't need any
special case in git-clean, i.e. -x would remove all untracked files,
whether ignored or garbage/trashable. That's what my patch to implement
it does:
https://public-inbox.org/git/87zhuf3gs0.fsf@evledraar.gmail.com/

I think that makes sense. Users running "git clean" have "--dry-run" and
unlike "checkout a branch" or "merge this commit" where we'll now shred
data implicitly it's obvious that git-clean is going to shred your data.

Then that't not what I want. If I'm going to mark to keep "config.mak"
around, I'm not going to carefully move it away before doing "git
clean -fdx" then move it back. No "git clean --dry-run" telling me to
make a backup of config.mak is no good.
-- 
Duy