Support Git Worktree projects

[p5]

Feel free to close this issue if you don't feel it should be implemented.

Is your feature request related to a problem? Not a problem, but an enhancement that could make working with devcontainers (and Git in general) easier. This is sort of a "support my specific git workflow" kind of request - an opinionated way of managing Git projects.

This may be a bit of a controversial one, but if this is disabled by default, it could become a selling point for DevPod. Feel free to close this issue if you don't feel it should be implemented. I'm sure I can create some sort of custom wrapper scripts can be created that calls GitPod CLI.

Which solution do you suggest? Have the option to create a Git Worktree project, rather than a regular git project. Worktrees can allow you to have a separate directory per branch. The main benefit is you never have to worry about stashing code or switching between branches. You simply open a file in a new directory.

This could simply be a checkbox that says "Use Git Worktree"

For example, my current Git project structure looks like this:

.
├── chore
│   ├── add-cleanup-workflow
│   └── scaffold-repository
├── default
│   └── main
├── feature
│   ├── add-automated-upgrades
│   └── global-just-alias
└── fix
    ├── mesa-va-drivers
    └── nouveau-disable-script

With each directory in the tree being a branch.

The setup process (automated in DevPod) would be something like:

$ git clone --bare <url> .bare
$ echo "gitdir: ./.bare" > .git
$ git worktree add default/<default-branch>
$ <open root of worktree in IDE>

When the user wants to start a new feature, they simply run:

$ git worktree add feature/<feature-name>
$ cd feature/<feature-name>
$ ls
( displays the contents of the repo root)

Which alternative solutions exist?

I think the alternative would be to create the Git Worktree project outside of DevPod, then point DevPod to the local git project.

Additional context

[p5]

I'm almost certain this feature request will be rejected, but thought it's worth a shot before working on some hacky script.

[pascalbreuninger]

Hi @p5, thanks for opening a feature request. I'm trying to wrap my head around how this would work on the remote machine, i.e. how exactly the flow should be here. The simplest version of this is checking out the bare repo on the remote, adding the default branch like you suggested in the code snippet, and then building the workspace based on the devcontainer.json in the default branch - but where do we go from here? You'd still need to add worktrees manually on the remote

[p5]

Thanks for the reply! Everything you mentioned sounds good.

but where do we go from here?

In my opinion, the next steps don't differ greatly from the existing implementation. The user would create a branch (or in this case, a worktree) to work on their project. Apologies if I misunderstood your question.

Instead of running:

$ git checkout -b new-login-page
$ touch README.md
$ git add README.md & git commit -m "Add README"
$ git push -u origin new-login-page

They (the users) would use

$ git worktree add feature/new-login-page
$ cd feature/new-login-page
$ touch README.md
$ git add README.md & git commit -m "Add README"
$ git push -u origin new-login-page

To switch back to the default branch, they simply run cd ../../default/<default-branch> (instead of stashing and checking out)

[pascalbreuninger]

sounds good to me 👍 let's put this on the roadmap. Can't make any promises as to when this will be shipped though. If you're curious, you can also give this feature a shot, I can support you whenever you need smth

[nneto]

Support for the git worktree feature would be very nice! I'm sad that this issue is forgotten for over a year.