Add Git Worktree Creation & Management to eGit (Eclipse Git UI)

[jgsuess]

Description

Add first-class Git worktree creation and management to eGit (Eclipse Git UI client). This should include UI support for the standard worktree lifecycle operations:

• Create a linked worktree (equivalent to git worktree add …) [git-scm.com]
• List/inspect worktrees associated with a repository (equivalent to git worktree list …) [git-scm.com]
• Lock/unlock worktrees (equivalent to git worktree lock|unlock …) [git-scm.com]
• Move / repair / prune / remove worktrees (equivalent to git worktree move|repair|prune|remove …) [git-scm.com]

At minimum, eGit should provide:

1. A “Create Worktree…” action from the Git Repositories view and/or Branches view.
2. A Worktrees view/section to display all worktrees for a repository, including path, branch/detached state, and locked/prunable state (as defined by Git). [git-scm.com]
3. Safe operations with guardrails aligned to Git semantics (e.g., warnings/removal constraints for “unclean” worktrees; lock preventing prune/move/delete unless forced). [git-scm.com]

---

Motivation

1) This is overdue; the request has existed since 2015

There is a long-standing Bugzilla ticket requesting worktree support in the Eclipse ecosystem: Bug 477475 – “Support git worktrees”.
For years, the common justification was “JGit doesn’t support it yet.” That excuse is obsolete. [bugs.eclipse.org]

2) JGit 7.0.0 materially removes the foundational blocker

JGit 7.0.0 introduced “Add worktrees read support” in its New Features list.
That is a pivotal step: the core Git library underpinning eGit is now worktree-aware at the repository layer. At this point, eGit’s lack of worktree support is not a Git limitation; it is a missing UI/integration layer that needs to catch up with the stack. [projects.eclipse.org]

3) Forceful point: Worktrees are the common repo‑sharing mechanism for AI agents

This is the practical reason the issue should be treated as priority modernization, not “nice-to-have”:

AI agents increasingly require parallel, isolated working directories per task/branch while sharing repository storage. Git worktrees are the cleanest and most efficient mechanism to do exactly that. Git explicitly defines worktrees as a way to “manage multiple working trees attached to the same repository” and “check out more than one branch at a time.” [git-scm.com]

In other words:

• Agents need concurrency + isolation + fast setup/teardown.
• Worktrees provide one branch per directory, without multiple clones. [git-scm.com]

If eGit cannot create and manage worktrees, Eclipse becomes the bottleneck in agent-assisted development workflows. Users will be forced into CLI + manual Eclipse project import/cleanup. That undermines the purpose of eGit as an integrated Git UI.

---

Alternatives considered

1. Use the Git CLI for worktree operations
   Users can run git worktree add/list/remove/prune/lock/unlock themselves.
   Why this is insufficient: It forces constant context switching, leads to misalignment between what Eclipse displays and what the repo actually contains, and turns common lifecycle actions into fragile manual procedures (especially when multiple worktrees are created and deleted frequently). [git-scm.com]

2. Clone the repository multiple times instead of using worktrees
   This is the classic workaround.
   Why this is inferior: It wastes disk space, duplicates object databases, increases fetch time, and adds overhead that worktrees were explicitly designed to avoid (multiple working directories attached to one repository). [git-scm.com]

3. Rely on “import projects from filesystem” and treat each worktree as a separate repo entry
   Some users may attempt to add each worktree path manually.
   Why this is insufficient: It’s a UI hack, not worktree management. It doesn’t provide create/remove/prune/lock semantics, nor does it reflect Git’s worktree states (locked/prunable/detached) directly. Git defines these states and commands explicitly; eGit should surface them. [git-scm.com]

---

Additional context

• Historical issue: Bugzilla 477475 exists as an earlier request for worktree support. This feature request should explicitly reference it as the long-running “paper trail,” and note that the ecosystem is now ready to finish the job. [bugs.eclipse.org]

• JGit capability milestone: In the JGit 7.0.0 release information, “Add worktrees read support” is listed under New Features. This is a credible anchor to state that JGit now has first-class awareness of worktrees at the library level, and that eGit should now expose the feature in the UI. [projects.eclipse.org]

• Canonical definition of worktrees and operations: The Git documentation defines worktrees as multiple working trees attached to the same repository and enumerates the management operations (add, list, lock, move, prune, remove, repair, unlock)—these are precisely the operations eGit should model in its UI. [git-scm.com]

[tomaswolf]

Not to forget:

• JGit should support creating worktrees.
• EGit will need to integrate git worktrees somehow with the Eclipse workspace, and might need to support a concept of switching worktrees. It's similar to switching between branches, but project locations change. Requiring different Eclipse workspaces for different git worktrees leads to a combinatorial explosion if Eclipse workspaces contain projects from different git repositories.