[GH-ISSUE #357] Feature Request: Support workspace with multiple independent git repositories #131

Closed
opened 2026-03-02 04:12:04 +03:00 by kerem · 11 comments
Owner

Originally created by @harvest-L on GitHub (Jan 16, 2026).
Original GitHub issue: https://github.com/git-ai-project/git-ai/issues/357

Originally assigned to: @Krishnachaitanyakc on GitHub.

Problem Description

Current git-ai doesn't properly support workspaces that contain multiple independent git repositories as subdirectories. The workspace root itself is not a git repository, but contains multiple git repositories as child directories.

Use Case

Scenario: Workspace Directory with Multiple Git Repos

workspace/                    (NOT a git repository)
├── project-backend/          (git repo A)
│   ├── .git/
│   └── src/
├── project-frontend/         (git repo B)
│   ├── .git/
│   └── src/
├── shared-library/           (git repo C)
│   ├── .git/
│   └── src/
└── documentation/            (git repo D)
    ├── .git/
    └── docs/

Common use cases:

  • Developer works on multiple related projects in one workspace
  • Code reviews spanning multiple repositories
  • Microservices with separate repos in one workspace
  • Monorepo split into multiple git repositories

Current Behavior

When AI agent edits files across multiple git repositories in this workspace:

  1. git-ai fails to initialize - Can't determine which git repository to use
  2. Attribution lost - AI edits in some repositories are not tracked
  3. Checkpoints fail - Working log creation fails for nested repositories
  4. Only one repository tracked - Only the first or "main" repository gets proper attribution tracking

Expected Behavior

git-ai should:

  1. Auto-detect nested git repositories in the workspace
  2. Track attributions per repository - Each subdirectory git repo gets its own attribution tracking
  3. Handle cross-repo edits in one AI session - Single AI session that edits multiple repos should be tracked correctly
  4. Support workspace-relative paths - Work with file paths relative to workspace root
  5. Create checkpoints per repository - Each git repository gets its own checkpoint

Example Workflow

workspace/
├── backend/.git
├── frontend/.git
└── shared/.git

# AI Session in Cursor/Claude Code:
User: "Add user authentication across backend, frontend, and shared"
AI: [Edits files in all three repositories]

# Expected result:
cd workspace/backend && git commit -m "Add auth"
→ git-ai blame shows correct AI attributions ✓

cd workspace/frontend && git commit -m "Add auth"
→ git-ai blame shows correct AI attributions ✓

cd workspace/shared && git commit -m "Add auth"
→ git-ai blame shows correct AI attributions ✓

Environment

  • git-ai version: 1.0.31
  • OS: Windows
  • IDE: VSCode, Cursor, Claude Code (multi-folder workspace)
  • AI tools: Claude Code, Cursor AI
  • Project setup:
    • Workspace root: NOT a git repository
    • Subdirectories: Each is an independent git repository

Current Workaround

No known workaround. Users must:

  • Open each repository in separate IDE windows (inefficient)
  • Work on one repository at a time (breaks AI workflow)
  • Lose attribution tracking for some repositories

Suggested Implementation

Approach 1: Per-Directory Git Detection

  • For each edited file, detect its git repository by walking up the directory tree
  • Create separate checkpoint/working log for each detected git repository
  • Maintain mapping of files to their respective git repositories

Approach 2: Workspace Configuration

  • Detect if workspace root has a .git-ai-workspace config
  • List all git repositories under the workspace
  • Track attributions per repository from a single AI session

Approach 3: Git Working Tree Support

  • Similar to git worktree - manage multiple working directories
  • Track attributions across all working trees in the workspace

Impact

This is a critical feature for:

  • Teams using microservices with separate repositories
  • Developers working on multiple related projects
  • Code review workflows spanning multiple repositories
  • Any organization with multiple related git repositories

Without this support, git-ai cannot be used effectively in modern development environments where AI agents work across multiple repositories simultaneously.

Originally created by @harvest-L on GitHub (Jan 16, 2026). Original GitHub issue: https://github.com/git-ai-project/git-ai/issues/357 Originally assigned to: @Krishnachaitanyakc on GitHub. ## Problem Description Current git-ai doesn't properly support workspaces that contain multiple independent git repositories as subdirectories. The workspace root itself is not a git repository, but contains multiple git repositories as child directories. ## Use Case **Scenario**: Workspace Directory with Multiple Git Repos ``` workspace/ (NOT a git repository) ├── project-backend/ (git repo A) │ ├── .git/ │ └── src/ ├── project-frontend/ (git repo B) │ ├── .git/ │ └── src/ ├── shared-library/ (git repo C) │ ├── .git/ │ └── src/ └── documentation/ (git repo D) ├── .git/ └── docs/ ``` **Common use cases**: - Developer works on multiple related projects in one workspace - Code reviews spanning multiple repositories - Microservices with separate repos in one workspace - Monorepo split into multiple git repositories ## Current Behavior When AI agent edits files across multiple git repositories in this workspace: 1. **git-ai fails to initialize** - Can't determine which git repository to use 2. **Attribution lost** - AI edits in some repositories are not tracked 3. **Checkpoints fail** - Working log creation fails for nested repositories 4. **Only one repository tracked** - Only the first or "main" repository gets proper attribution tracking ## Expected Behavior git-ai should: 1. **Auto-detect nested git repositories** in the workspace 2. **Track attributions per repository** - Each subdirectory git repo gets its own attribution tracking 3. **Handle cross-repo edits in one AI session** - Single AI session that edits multiple repos should be tracked correctly 4. **Support workspace-relative paths** - Work with file paths relative to workspace root 5. **Create checkpoints per repository** - Each git repository gets its own checkpoint ## Example Workflow ``` workspace/ ├── backend/.git ├── frontend/.git └── shared/.git # AI Session in Cursor/Claude Code: User: "Add user authentication across backend, frontend, and shared" AI: [Edits files in all three repositories] # Expected result: cd workspace/backend && git commit -m "Add auth" → git-ai blame shows correct AI attributions ✓ cd workspace/frontend && git commit -m "Add auth" → git-ai blame shows correct AI attributions ✓ cd workspace/shared && git commit -m "Add auth" → git-ai blame shows correct AI attributions ✓ ``` ## Environment - git-ai version: 1.0.31 - OS: Windows - IDE: VSCode, Cursor, Claude Code (multi-folder workspace) - AI tools: Claude Code, Cursor AI - Project setup: - Workspace root: NOT a git repository - Subdirectories: Each is an independent git repository ## Current Workaround No known workaround. Users must: - Open each repository in separate IDE windows (inefficient) - Work on one repository at a time (breaks AI workflow) - Lose attribution tracking for some repositories ## Suggested Implementation **Approach 1: Per-Directory Git Detection** - For each edited file, detect its git repository by walking up the directory tree - Create separate checkpoint/working log for each detected git repository - Maintain mapping of files to their respective git repositories **Approach 2: Workspace Configuration** - Detect if workspace root has a `.git-ai-workspace` config - List all git repositories under the workspace - Track attributions per repository from a single AI session **Approach 3: Git Working Tree Support** - Similar to `git worktree` - manage multiple working directories - Track attributions across all working trees in the workspace ## Impact This is a **critical feature** for: - Teams using microservices with separate repositories - Developers working on multiple related projects - Code review workflows spanning multiple repositories - Any organization with multiple related git repositories Without this support, git-ai cannot be used effectively in modern development environments where AI agents work across multiple repositories simultaneously.
kerem 2026-03-02 04:12:04 +03:00
Author
Owner

@svarlamov commented on GitHub (Jan 16, 2026):

Hey @harvest-L thanks for the report! There's definitely still some rough edges when in multi-root workspaces.

Can you test this with Cursor on the latest release of git-ai? It should be fixed ref: https://github.com/acunniffe/git-ai/pull/337

As far as the other IDEs, I just wanted to double check, which ones were you able to actually replicate the issue in? I ask because this functionality is pretty IDE/agent-specific. Thanks!

<!-- gh-comment-id:3761574452 --> @svarlamov commented on GitHub (Jan 16, 2026): Hey @harvest-L thanks for the report! There's definitely still some rough edges when in multi-root workspaces. Can you test this with Cursor on the latest release of git-ai? It should be fixed ref: https://github.com/acunniffe/git-ai/pull/337 As far as the other IDEs, I just wanted to double check, which ones were you able to actually replicate the issue in? I ask because this functionality is pretty IDE/agent-specific. Thanks!
Author
Owner

@harvest-L commented on GitHub (Jan 17, 2026):

I discovered this issue in both Claude and Cursor. I'm using the latest version 1.0.35 of git-ai. The call log is
as follows:

Claude:
Edit [git-ai checkpoint claude --hook-input stdin] failed with non-blocking status code 1: Failed
to find repository: Git CLI (-C C:\Users\rog\work\my rev-parse --absolute-git-dir --show-toplevel) failed with
exit code 128: fatal: not a git repository (or any of the parent directories): .git

Cursor
{
"conversation_id": "a22c8dcf-0441-4683-888e-7c20695c2c9f",
"generation_id": "1fa5ad11-893d-4117-9ca8-96845588c6cb",
"model": "default",
"file_path": "c:\Users\rog\work\my\git-ai-stats-test\hello.js",
"edits": [
{
"old_string": "function hello() { \n console.log("Hello"); \n console.log("World");\n console.log("!");\n}",
"new_string": "function hello() { \n console.log("Hello"); \n console.log("World");\n console.log("!");\n console.log("新添加的打印");\n}"
}
],
"hook_event_name": "afterFileEdit",
"cursor_version": "2.3.35",
"workspace_roots": [
"/C:/Users/rog/work/my"
],
"user_email": ""
}

Failed to find repository: Git CLI (-C C:\Users\rog\work\my rev-parse --absolute-git-dir --show-toplevel) failed with exit code 128: fatal: not a git repository (or any of the parent directories): .git

<!-- gh-comment-id:3762935025 --> @harvest-L commented on GitHub (Jan 17, 2026): I discovered this issue in both Claude and Cursor. I'm using the latest version 1.0.35 of git-ai. The call log is as follows: Claude: Edit [git-ai checkpoint claude --hook-input stdin] failed with non-blocking status code 1: Failed to find repository: Git CLI (-C C:\Users\rog\work\my rev-parse --absolute-git-dir --show-toplevel) failed with exit code 128: fatal: not a git repository (or any of the parent directories): .git Cursor { "conversation_id": "a22c8dcf-0441-4683-888e-7c20695c2c9f", "generation_id": "1fa5ad11-893d-4117-9ca8-96845588c6cb", "model": "default", "file_path": "c:\\Users\\rog\\work\\my\\git-ai-stats-test\\hello.js", "edits": [ { "old_string": "function hello() { \n console.log(\"Hello\"); \n console.log(\"World\");\n console.log(\"!\");\n}", "new_string": "function hello() { \n console.log(\"Hello\"); \n console.log(\"World\");\n console.log(\"!\");\n console.log(\"新添加的打印\");\n}" } ], "hook_event_name": "afterFileEdit", "cursor_version": "2.3.35", "workspace_roots": [ "/C:/Users/rog/work/my" ], "user_email": "" } Failed to find repository: Git CLI (-C C:\Users\rog\work\my rev-parse --absolute-git-dir --show-toplevel) failed with exit code 128: fatal: not a git repository (or any of the parent directories): .git
Author
Owner

@svarlamov commented on GitHub (Jan 18, 2026):

Thanks, I think I'm clear on the issue now. I believe the solution for this is, probably for both AI and human checkpoints, to pick the repo based on the actual file(s) that are being edited.

Example 1

Workspace: /Users/svarlamov/projects
File edited: /Users/svarlamov/projects/git-ai/README.md
Git dir used: should be /Users/svarlamov/projects/git-ai

Example 2

Workspaces: [/Users/svarlamov/projects, /Users/svarlamov/Documents]
File edited: /Users/svarlamov/projects/git-ai/README.md
Git dir used: should be /Users/svarlamov/projects/git-ai

Example 3

Workspaces: [/Users/svarlamov/Documents]
File edited: /Users/svarlamov/projects/git-ai/README.md
Git dir used: should be: /Users/svarlamov/projects/git-ai

Test cases must verify that submodules are ignored and git dirs inside of another git dir are skipped in favor of their parent, unless the parent is above the level of the workspace (use the one at the same level or below the workspace). I'm sure there's probably more edge cases that maybe the agents can help to think of here.

@Krishnachaitanyakc Just tagging you here in case you have any interest in picking this issue up as you explore Git AI 😊

<!-- gh-comment-id:3765492988 --> @svarlamov commented on GitHub (Jan 18, 2026): Thanks, I think I'm clear on the issue now. I believe the solution for this is, probably for both AI and human checkpoints, to pick the repo based on the actual file(s) that are being edited. #### Example 1 Workspace: `/Users/svarlamov/projects` File edited: `/Users/svarlamov/projects/git-ai/README.md` Git dir used: should be `/Users/svarlamov/projects/git-ai` #### Example 2 Workspaces: [`/Users/svarlamov/projects`, `/Users/svarlamov/Documents`] File edited: `/Users/svarlamov/projects/git-ai/README.md` Git dir used: should be `/Users/svarlamov/projects/git-ai` #### Example 3 Workspaces: [`/Users/svarlamov/Documents`] File edited: `/Users/svarlamov/projects/git-ai/README.md` Git dir used: should be: `/Users/svarlamov/projects/git-ai` Test cases must verify that submodules are ignored and git dirs inside of another git dir are skipped in favor of their parent, unless the parent is above the level of the workspace (use the one at the same level or below the workspace). I'm sure there's probably more edge cases that maybe the agents can help to think of here. @Krishnachaitanyakc Just tagging you here in case you have any interest in picking this issue up as you explore Git AI 😊
Author
Owner

@Krishnachaitanyakc commented on GitHub (Jan 18, 2026):

@svarlamov would love to. Can you assign the issue to me?

<!-- gh-comment-id:3765539423 --> @Krishnachaitanyakc commented on GitHub (Jan 18, 2026): @svarlamov would love to. Can you assign the issue to me?
Author
Owner

@svarlamov commented on GitHub (Jan 18, 2026):

@Krishnachaitanyakc Sorry for the delay -- assigned. Thank you so much for taking this on. You rock! Will prioritize the review when I see the PR ❤️

<!-- gh-comment-id:3765746904 --> @svarlamov commented on GitHub (Jan 18, 2026): @Krishnachaitanyakc Sorry for the delay -- assigned. Thank you so much for taking this on. You rock! Will prioritize the review when I see the PR ❤️
Author
Owner

@harvest-L commented on GitHub (Jan 19, 2026):

@svarlamov
Here might be another request: for the command git-ai checkpoint agent-v1, the repo_working_dir parameter is currently mandatory. If this issue is fixed, it seems this parameter could be set as optional.

Let me explain why I’m making this request:

Previously, within my company, I developed a small tool similar to git-ai, also using two checkpoints + diff. However, compared to the maturity and power of git-ai, my tool is quite limited. But my checkpoint triggering method differs from git-ai’s—I use MCP + some mandatory rules, mainly to make the AI execute this checkpoint before and after editing files. Although MCP might not be as stable as hooks, one advantage is its compatibility with most AI agents. I’ve tested it with many AI agents, and it works in most cases. Perhaps this could serve as a transitional solution in the current environment (where hooks are still not widely supported by many agents). I’ve also integrated git-ai into antigravity via MCP, and it seems to work well.

On another note, I have to say that git-ai’s promotion efforts seem lacking—otherwise, I wouldn’t have reinvented the wheel. When I tried to promote my tool internally, I realized it had too much to handle. Eventually, after searching through various search engines and AI platforms, I finally discovered git-ai. I think git-ai is an excellent product, and our company plans to use it as an efficiency tool. We currently have around 200 R&D staff.

Also, regarding the data metrics server, I noticed it’s no longer mentioned on the official website. Is it a paid service? I’d like to learn more about it and look forward to your reply.

<!-- gh-comment-id:3766128533 --> @harvest-L commented on GitHub (Jan 19, 2026): @svarlamov Here might be another request: for the command git-ai checkpoint agent-v1, the repo_working_dir parameter is currently mandatory. If this issue is fixed, it seems this parameter could be set as optional. Let me explain why I’m making this request: Previously, within my company, I developed a small tool similar to git-ai, also using two checkpoints + diff. However, compared to the maturity and power of git-ai, my tool is quite limited. But my checkpoint triggering method differs from git-ai’s—I use MCP + some mandatory rules, mainly to make the AI execute this checkpoint before and after editing files. Although MCP might not be as stable as hooks, one advantage is its compatibility with most AI agents. I’ve tested it with many AI agents, and it works in most cases. Perhaps this could serve as a transitional solution in the current environment (where hooks are still not widely supported by many agents). I’ve also integrated git-ai into antigravity via MCP, and it seems to work well. On another note, I have to say that git-ai’s promotion efforts seem lacking—otherwise, I wouldn’t have reinvented the wheel. When I tried to promote my tool internally, I realized it had too much to handle. Eventually, after searching through various search engines and AI platforms, I finally discovered git-ai. I think git-ai is an excellent product, and our company plans to use it as an efficiency tool. We currently have around 200 R&D staff. Also, regarding the data metrics server, I noticed it’s no longer mentioned on the official website. Is it a paid service? I’d like to learn more about it and look forward to your reply.
Author
Owner

@svarlamov commented on GitHub (Jan 19, 2026):

@harvest-L We should definitely talk! Do you have some time to chat? https://calendly.com/acunniffe/meeting-with-git-ai-authors

<!-- gh-comment-id:3768615912 --> @svarlamov commented on GitHub (Jan 19, 2026): @harvest-L We should definitely talk! Do you have some time to chat? https://calendly.com/acunniffe/meeting-with-git-ai-authors
Author
Owner

@harvest-L commented on GitHub (Jan 19, 2026):

@svarlamov
Thank you for your reply and the invitation to chat. I really appreciate your time.

To be honest, my English is not very good, and I rely heavily on AI tools to communicate. I’m a bit concerned that I might not be able to express myself clearly during a live conversation, and I wouldn’t want to waste your valuable time.

If possible, could you share more information about your server product via email? I’d be happy to read through it and follow up with any questions I may have.

My email is: flyharvest@yeah.net

<!-- gh-comment-id:3768842153 --> @harvest-L commented on GitHub (Jan 19, 2026): @svarlamov Thank you for your reply and the invitation to chat. I really appreciate your time. To be honest, my English is not very good, and I rely heavily on AI tools to communicate. I’m a bit concerned that I might not be able to express myself clearly during a live conversation, and I wouldn’t want to waste your valuable time. If possible, could you share more information about your server product via email? I’d be happy to read through it and follow up with any questions I may have. My email is: flyharvest@yeah.net
Author
Owner

@Krishnachaitanyakc commented on GitHub (Feb 8, 2026):

@svarlamov let's close out this issue?

<!-- gh-comment-id:3868419400 --> @Krishnachaitanyakc commented on GitHub (Feb 8, 2026): @svarlamov let's close out this issue?
Author
Owner

@svarlamov commented on GitHub (Feb 12, 2026):

@Krishnachaitanyakc sorry for the late reply on this. @harvest-L did we get everything done here? everything working?

<!-- gh-comment-id:3893812463 --> @svarlamov commented on GitHub (Feb 12, 2026): @Krishnachaitanyakc sorry for the late reply on this. @harvest-L did we get everything done here? everything working?
Author
Owner

@svarlamov commented on GitHub (Feb 12, 2026):

Closing since it seems like this was fixed, but please ask to reopen if not

<!-- gh-comment-id:3893813451 --> @svarlamov commented on GitHub (Feb 12, 2026): Closing since it seems like this was fixed, but please ask to reopen if not
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/git-ai#131
No description provided.