Re: [PATCH v3 8/8] sparse-checkout: clear tracked sparse dirs

Hi Elijah,

On Fri, 20 Aug 2021, Elijah Newren wrote:

On Thu, Aug 19, 2021 at 1:48 AM Johannes Schindelin
[off-list ref] wrote:

quoted

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