How to propagate or inherit certain buckconfig settings in child cells?

[thoughtpolice]

I have a .buckconfig in the root of the project (that is, next to .buckroot) that looks like this:

[repositories]
root = .
third-party = third-party/

[project]
ignore = \
  .jj, \
  .git, \
  .direnv, \
  .watchman-cookie** \
  work

To make some things easier to refer to, I gave several of the top-level directories in this project their own cells like third-party//, so they have their own .buckconfig that looks like this (under third-party/.buckconfig):

[repositories]
third-party = .

However, when I build something out of the third-party// cell, it does not inherit the top-level project.ignore:

$ buck2 build third-party//sqlite:shell
File changed: root//.watchman-cookie-GANON-19124-6468
File changed: third-party//sqlite/BUILD
File changed: root//.watchman-cookie-GANON-19124-6469
9 additional file change events
Build ID: 8430ac14-7f80-4e1c-9af9-7e1ff47a08e9
Network: Up: 0B  Down: 0B
Jobs completed: 20. Time elapsed: 0.0s.

Notably, even though I ran the build from the root directory of the project (i.e. what you would call root//), it still used the .buckconfig file from the third-party// cell, so it didn't ignore the .watchman-cookie files and instead saw them as changed.

The only current solution I see is duplicating the project.ignore setting across the .buckconfig of every single cell, but obviously this is kind of unfortunate and easy to mess up. This is my complaint, and what I would like to avoid. So I'd like a way to propagate or inherit this setting to child cells.

To be fair, I understand why this is the case overall and as the default; certain properties should definitely not be inherited by default. But would it be possible for certain "special" cases like project.ignore to propagate downwards? That would be an immediate fix but it's possibly not the best. Or maybe this should be handled through PACKAGE files or something, somehow? Should there be a new project.global_ignore? Or maybe there should be a new a [root] section that can only be specified in the top-level root .buckconfig file? I don't really know, but I'd like to just specify this setting once.

[thoughtpolice]

And just to be clear, while a generalized solution that could work for any setting would be fantastic, I'd absolutely just settle for a few special cases or alternative that could handle this case without repetition, too.

[ndmitchell]

In general we want only things that impact core Buck2 in the .buckconfig and most other things in PACKAGE files or constraints. But in this case, I think it does belong in the .buckconfig.

We are also generally moving to the idea that in most cases the root .buckconfig should be consulted where possible, but perhaps there are legitimate use case for excluding different things in different cells - e.g. if you want to exclude foo/bar in the root cell but not child cells.

The combination of those two things means we probably don't want try generalising this too much.

Maybe we could have the rule that if a cell doesn't have project-ignore, then we use the root one? That seems probably quite reasonable? Only issue is that relative paths e.g. foo/bar mean different things in the parent vs the root. This all seems disturbingly tricky to design right...

[thoughtpolice]

Frankly, although I hate the proliferation of these kinds of files, would it be any easier from an implementation POV to just have a single root file named .buckignore that just operates basically like .gitignore, and move the whole configuration out of the config file entirely? There's even a crate for that. There could be a rule that if not .buckignore file exists it is fully inherited from the parent cell .buckignore, in which case they are not merged and the child cell takes precedence. So if somebody wanted to override the parent config and reset itself back to zero, they could just touch .buckignore an empty file.

This is really no different than the status quo today except it has a different UX (by default cells have to turn off inheritance by touching an empty file, versus turning it on by copy-pasting.) But maybe it's enough.

I guess it is mostly a matter of if you want to support the "different exclusions in different cell" case, which does seem legitimate.

[ndmitchell]

I'd love the idea of just following the .gitignore spec as is, looking at the .gitignore files, with the override that if there is a .buckignore in the folder we use that instead of .gitignore. There are rules around inheritance etc in .gitignore (mostly that they are additive), and I see no reason to change them. Probably harder to implement than the existing scheme, but seems much more like what people would expect.

CC @cjhopman - would that be a good or bad idea?