On Tue, Mar 29 2022, Taylor Blau wrote: > On Tue, Mar 29, 2022 at 11:04:18AM +0200, Ævar Arnfjörð Bjarmason wrote: >> >> On Wed, Mar 23 2022, Taylor Blau wrote: >> >> > On Wed, Mar 23, 2022 at 03:22:13PM -0400, Derrick Stolee wrote: >> >> On 3/23/2022 2:03 PM, Josh Steadmon wrote: >> >> > prepare_repo_settings() initializes a `struct repository` with various >> >> > default config options and settings read from a repository-local config >> >> > file. In 44c7e62 (2021-12-06, repo-settings:prepare_repo_settings only >> >> > in git repos), prepare_repo_settings was changed to issue a BUG() if it >> >> > is called by a process whose CWD is not a Git repository. This approach >> >> > was suggested in [1]. >> >> > >> >> > This breaks fuzz-commit-graph, which attempts to parse arbitrary >> >> > fuzzing-engine-provided bytes as a commit graph file. >> >> > commit-graph.c:parse_commit_graph() calls prepare_repo_settings(), but >> >> > since we run the fuzz tests without a valid repository, we are hitting >> >> > the BUG() from 44c7e62 for every test case. >> >> > >> >> > Fix this by refactoring prepare_repo_settings() such that it sets >> >> > default options unconditionally; if its process is in a Git repository, >> >> > it will also load settings from the local config. This eliminates the >> >> > need for a BUG() when not in a repository. >> >> >> >> I think you have the right idea and this can work. >> > >> > Hmmm. To me this feels like bending over backwards in >> > `prepare_repo_settings()` to accommodate one particular caller. I'm not >> > necessarily opposed to it, but it does feel strange to make >> > `prepare_repo_settings()` a noop here, since I would expect that any >> > callers who do want to call `prepare_repo_settings()` are likely >> > convinced that they are inside of a repository, and it probably should >> > be a BUG() if they aren't. >> >> I think adding that BUG() was overzelous in the first place, per >> https://lore.kernel.org/git/211207.86r1apow9f.gmgdl@xxxxxxxxxxxxxxxxxxx/; > > I think Junio raised a good point in > > https://lore.kernel.org/git/xmqqcznh8913.fsf@gitster.g/ > > , though some of the detail was lost in 44c7e62e51 (repo-settings: > prepare_repo_settings only in git repos, 2021-12-06). > >> I have that in my local integration branch, because I ended up wanting >> to add prepare_repo_settings() to usage.c, which may or may not run >> inside a repo (and maybe we'll have that config, maybe not). > > I see what you're saying, though I think we would be equally OK to have > a default value of the repo_settings struct that we could rely on. I > said some of this back in > > https://lore.kernel.org/git/Yjt6mLIfw0V3aVTO@nand.local/ > > , namely the parts around "I would expect that any callers who do want > to call `prepare_repo_settings()` are likely convinced that they are > inside of a repository, and it probably should be a BUG() if they > aren't." > > Thinking in terms of your message, though, I think the distinction (from > my perspective, at least) is between (a) using something called > _repo_-settings in a non-repo context, and (b) calling a function which > is supposed to fill in its values from a repository (which the caller > implicitly expects to exist). > > Neither feel _good_ to me, but (b) feels worse, since it is making it OK > to operate in a likely-unexpected context with respect to the caller's > expectations. I agree that it's a bit iffy. I'm basically advocating for treating "the_repository->settings" as though it's a new "the_config" or whatever. Maybe we'd be better off just making that move, or having the_repository->settings contain only settings relevant to cases where we only have a repository. But I think predicating useful uses of it on that refactoring is overdoing it a bit, especially as I think your "(b)" concern here is already something we deal with when it comes to initialize_the_repository() and checks for "the_repository->gitdir". Can't we just have callers that really care about the distinction check "->gitdir" instead? As they're already doing in some cases already? Or just: git mv {repo,global}-settings.c Since that's what it seems to want to be anyway. > Anyway, I think that we are pretty far into the weeds, and it's likely > time to turn around. I don't have that strong a feeling either way, and > in all honesty either approach is probably just fine. *nod*
