Nix's git fetcher (git+file://, and the auto-detection used by plain path:/directory flakes) identifies a repository by the presence of a .git directory, and reads dirty-tree state and revision info directly against it.
Game of Trees (got) is a version control client that's fully compatible with the standard Git repository/object format, but uses its own work tree layout: a .got metadata directory instead of .git, with the actual repository (and .git directory) potentially living at a separate path referenced from the work tree's metadata.
Practical effect: a directory checked out via got checkout and managed entirely with got has no .git directory at all. Nix's fetcher doesn't recognize it as a git repository, silently falls back to treating it as a plain path: input, and as a result:
No dirty-tree detection/warning
.gitignore is not respected (full directory contents get copied into the store)
No self.rev/self.shortRev - revision info is unavailable
I wanted to check first whether this is something maintainers would consider in scope before attempting an implementation. My rough understanding is it'd need something like: detect .got in addition to .git, resolve the actual repository path from the work tree's metadata (got stores this per the got-worktree(5) format), then run the existing git-based logic against that resolved path while still diffing file contents against the .got-managed work tree.
I'm happy to open a PR or dig into this more. Also open to being told this is too niche to be worth upstream support, in which case I'll look at maintaining this out-of-tree instead.
Nix's git fetcher (git+file://, and the auto-detection used by plain path:/directory flakes) identifies a repository by the presence of a .git directory, and reads dirty-tree state and revision info directly against it.
Game of Trees (got) is a version control client that's fully compatible with the standard Git repository/object format, but uses its own work tree layout: a .got metadata directory instead of .git, with the actual repository (and .git directory) potentially living at a separate path referenced from the work tree's metadata.
Practical effect: a directory checked out via got checkout and managed entirely with got has no .git directory at all. Nix's fetcher doesn't recognize it as a git repository, silently falls back to treating it as a plain path: input, and as a result:
No dirty-tree detection/warning
.gitignore is not respected (full directory contents get copied into the store)
No self.rev/self.shortRev - revision info is unavailable
I wanted to check first whether this is something maintainers would consider in scope before attempting an implementation. My rough understanding is it'd need something like: detect .got in addition to .git, resolve the actual repository path from the work tree's metadata (got stores this per the got-worktree(5) format), then run the existing git-based logic against that resolved path while still diffing file contents against the .got-managed work tree.
I'm happy to open a PR or dig into this more. Also open to being told this is too niche to be worth upstream support, in which case I'll look at maintaining this out-of-tree instead.