Support .jj as well as .git

[fowles]

• Allow .jj dirs to count as vcs directories.
• Simplify the control flow around resolving info/exclude

[fowles]

I totally understand if you don't want to expand things to support every oddball VCS, but so many tools I like (cargo watch, rg, fzf, fd) are all built on this common library that adding a bit of support at the core gets a lot of things to just work.

[fowles]

any chance I can get this considered?

[BurntSushi]

I think my main concerns here are:

1. I don't even know what .jj is referring to. You didn't give a link or explain anything.
2. This patch seems to assume that .jj and .git have identical semantics. Do they? There are literally no differences?
3. This doubles the number of stat calls for every directory ripgrep searches. This is a rather annoying hurdle because I don't want this to be used as a bludgeon to forever fix ourselves to git. But at the same time, there is a cost here that needs to be weighed with the benefit.

[fowles]

Sorry about the lack of link, that is my bad. https://martinvonz.github.io/jj/latest/ is the best spot to read. It is a version control system like git, so .jj is a directory that contains metadata for it (just like .git).

As an alternate suggestion, I would recommend respecting .gitignore files even when there is no .git directory. Then you can cut the stat calls down from 1 to zero.

[BurntSushi]

As an alternate suggestion, I would recommend respecting .gitignore files even when there is no .git directory. Then you can cut the stat calls down from 1 to zero.

That already exists today with --no-require-git. But vcs directory detection is in general required for correctness so that you don't let gitignore files cross repository boundaries.

[fowles]

The problem that I run into with --no-require-git is that every tool built on the library exposes it differently (and some don't). Is there a way to make that controlled via env variable or something?

[BurntSushi]

No. I personally think that would be wildly inappropriate. ignore isn't a "standard," and trying to reach out into the environment in a library to do an end-runaround on the CLI interface just seems really bad to me. Like, there would, by construction, be no coupling between the environment variable and the CLI, which means there would be no way for ignore to know when to respect the environment variable versus some other option (which might override the environment variable). The only way to solve that would be to introduce more API machinery to deal with it. Sounds awful.

I'm not saying No to this PR, but it's going to require that I or someone goes and understands jj to ensure this is implemented correctly. At minimum. And I'll also need to make a judgment of whether the cost is worth it.

[fowles]

I checked with folks on the jj discord to make sure that I was getting all the corners. I have updated the PR with that and also moved things around a tiny bit to minimize the number of stat calls as well as the number of allocations.

I absolutely understand that this is a judgement call on your end about complexity versus general utility. If there is any data I can provide to make that case, I would be happy to try, but I recognize that jj is a niche VCS. (I have hopes it will grow, but realistically I am not sure it will.)

[fowles]

Did you have a chance to come to a conclusion here?

[fowles]

Following up, I have verified this PR with jj's owner (and I am also a committer on it). So I think this is ready for review (pending your actual acceptance of the direction).

Thanks!