On Thu, Apr 07 2022, Derrick Stolee wrote: > A more complete protection here would be: > > 1. Warn when finding a bare repo as a tree (this patch). > > 2. Suppress warnings on trusted repos, scoped to a specific set of known > trees _or_ based on some set of known commits (in case the known trees > are too large). > > 3. Prevent writing a bare repo to the worktree, unless the user provided > an opt-in to that behavior. > > Since your patch is moving in the right direction here, I don't think > steps (2) and (3) are required to move forward with your patch. However, > it is a good opportunity to discuss the full repercussions of this issue. Isn't a gentler solution here to: 1. In setup.c, we detect a repo 2. Walk up a directory 3. Do we find a repo? 4. Does that repo "contain" the first one? If yes: die on setup If no: it's OK It also seems to me that there's pretty much perfect overlap between this and the long-discussed topic of marking a submodule with config v.s. detecting it on the fly. Since we're already discussing breaking long-standing repos in the wild here I think it's good to take a step back and think of a potential more narrow solution. There's nothing wrong with having tracked content per-se, it's just that we ourselves have other code that'll shoot itself in the foot in certain scenarios, like this one. But for a newer git that needs to run this fsck check it'll already need to detect that something "looks like a repo", but if it can do that and setup.c can walk up from the parent directory & find a repository we can combine the two. Of course we'll probably still want an opt-in fsck check for hosting providers who'll want to protect older clients, but as long as the two are separated that'll only need to last as long as such clients are potentially there in the wild.