On Mon, Nov 26, 2018 at 4:34 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Mon, Nov 26 2018, Duy Nguyen wrote: > > > On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg <per.lundberg@xxxxxxxx> wrote: > >> > >> 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. > > > > 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. -- Duy
