On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > >> >> 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@xxxxxxxxxxxxxxxxxxx/ > >> > >> 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. > > Understood. I mean this in the context of solving the problem users have > with running otherwise non-data-destroying commands like "checkout" and > "merge" and getting their data destroyed, which is overwhelmingly why > this topic gets resurrected. > > Some of the solutions overlap with this thing you want, but I think it's > worth keeping the distinction between the two in mind. On the other hand all use cases should be considered. It's going to be a mess to have "trashable" attribute that applies to some commands while "precious" to some others (and even worse when they overlap, imagine having to define both in .gitattributes) > I.e. I can > imagine us finding some acceptable solution to the data shredding > problem that doesn't implement this mode for "git-clean", or the other > way around. -- Duy
