- No support for LFS
- No support for hooks (precommit, etc)
- No? Bad? support for submodules
- No? Bad? support for line ending styles
If you don't care about those, you _should_ be able to use jj completely "undetected". It does encourage rewriting history more than some git workflows like.
In terms of issues in the git repo -- there shouldn't be any. jj uses git as a backend, all commits are stored as git commits, etc. If you colocate the repo, you're able to use git commands directly.
If you had multiple people working on a branch and only some were using jj, then those not using jj would likely have issues with all of the rebasing and force pushes that happen behind the scenes to keep the history clean.
If you were to enforce linear history (like in GitHub) and used rebase merges exclusively then I think it's ideal, especially in terms of reviewing smaller, incremental changes rather than huge pull request diffs.
No support in the sense that jj won't do anything with them, but you can collocate the repository and use git to deal with them and it's fine.
> - No? Bad? support for line ending styles
That's a No, currently, yeah.
There's plenty about how you can use jj as a replacement but no clear guidance on what upstream commits will actually look like if you use it.