Hi Elijah, On Fri, 20 Aug 2021, Elijah Newren wrote: > On Thu, Aug 19, 2021 at 1:48 AM Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > Having said that, even after mulling over this behavior and sleeping > > over it, I am unsure what the best way forward would be. Just because > > it is easy to explain does not make it right. > > > > It is tricky to decide mostly because "ignored" files are definitely > > not always build output. Apart from VIM's temporary files, users like > > me frequently write other files and/or directories that we simply do > > not want to see tracked in Git. For example, I often test things in an > > `a1.c` file that -- for convenience -- lives in the current worktree. > > Obviously I don't want Git to track it, but I also don't want it to be > > deleted, so I often add corresponding lines to `.git/info/exclude`. > > Likewise, I sometimes download additional information related to what > > I am implementing, and that also lives in the current worktree (but > > then, I usually am too lazy to add an entry to `.git/info/exclude` in > > those cases). > > I do the same thing, and I know other users that do as well...but I > don't put such files in directories that are irrelevant to me. I create > cruft files near other files that I'm working on, or in a special > directory of its own, but not under some directory that is irrelevant to > the areas I'm working on. > > For reference, we implemented something like this in our `sparsify` > wrapper we have internally, where 'git clean -fdX <all sparse > directories>` is executed whenever folks sparsify. (We have our own > tool and don't have users use sparse-checkout directly, because our tool > computes dependencies to determine which directories are needed.) I was > really hesitant to add that cleaning behavior by default, and just made > it an option. My colleagues tired of all the bug reports about > left-around directories and made it the default, waiting to hear > complaints. We never got one. It's been over a year. It is really nice to hear that you have evidence from users using this in practice. I find that very convincing, and it weighs much more than all of my (very theoretical) considerations. Thank you, Dscho
