Improved Utility with Git Worktrees

[navarr]

I'm starting to explore how to use git worktrees, and thinking of how working with Warden in them could be made a little easier.

My first thought is that we essentially would want a way to base WARDEN_ENV_NAME and TRAEFIK_DOMAIN on a variable (like the folder name) and the rest would fall into place. I don't think we'll ever be able to avoid the new worktree = new setup, but at least being able to keep the same .env between branches would be nice, in my mind.

[bap14]

I would agree with new worktree = new setup. Especially with Magento environments, having the shared resources across worktrees could lead to some odd issues (like database schema changes / updates, caching, etc).

I think having things default to current environment folder name makes sense (at least to me) and you can override it if you want. Would make warden env-init simpler; however, we may have to support named parameters (or alter the parameter order) which would necessitate a "major" version bump.

[navarr]

I've been thinking about this some more today, and am wondering if it would be as simple as a flag like WARDEN_WORKTREE=1 that, when set:

• Prepends the $(basename $PWD) to the TRAEFIK_DOMAIN variable as a subdomain (so a folder develop might become develop.warden-project.test
• Appends -$(basename $PWD) to the WARDEN_ENV_NAME variable (so a folder develop might become warden-project-develop

I think this would satisfy most use cases and (hopefully?) be a fairly straight-forward addition.

[bap14]

That seems a reasonable approach

[ilnytskyi]

For my use case, I don't think anything needs to be changed on the Warden side for now.

I've built a custom script that replaces a couple of environment variables and builds the project, which works well for my setup.

At most, I could see something like a warden worktree new <name or localtion> wrapper that creates a Git worktree and automatically adjusts the environment configuration.

However, I think this could quickly grow into a fairly complex feature that needs to be highly customizable:

• Worktree naming and location — how and where should worktrees be created?
• Base branch — should we use the current branch, master, or any explicitly specified branch?
• Multiple worktrees — what if we want to spin up 5–10 worktrees from the same base to test different scenarios in parallel?
• Cleanup — how do we destroy worktrees and clean up their associated Docker resources?
• Project-specific initialization — what additional steps should run after creating a worktree?

For example, my custom script also supports copying a database directly between Docker volumes and applying additional fixtures after the copy.

Another complication I've encountered is Git integration. Some of my tests depend on Git metadata, and I also use Git hooks. With linked worktrees, .git is normally a file pointing to metadata stored elsewhere, which can cause problems when only the worktree directory is mounted into a container.

There are several ways around this, but none seem particularly clean or universal. In some cases, simply cloning the repository into another directory might be easier than using Git worktrees at all.

This also overlaps with environment-specific decisions. For example, some macOS development environments using Mutagen exclude .git from synchronization, creating similar limitations even without worktrees.

Once we start covering these use cases, it's no longer just a simple warden worktree new <name> command. It becomes a worktree lifecycle management tool that needs to be maintained and extended over time.

I'd suggest keeping this outside Warden core, potentially as an optional plugin or a standalone wrapper around Warden.

We could also look at how projects like DDEV handle customizable lifecycle hooks and project-specific automation.

In this article: https://ddev.com/blog/git-worktree-contributor-training/ DDEV litteraly have a block of custom code to move DB from one worktree to another

For now, I'd probably suggest doing nothing in Warden core unless we identify a small, generic capability that's genuinely missing and would benefit multiple workflows.

Also most of work now is done with AI agent, for them worktrees are native thing they only need a few instructions on how to build and run project after worktree created.