Does git worktree allow "pulling" from a different worktree?

Question

I am working on the main worktree to test my own code for unit tests. I created another work tree (let's call it integration) to build a bigger executable as my own code is just a dependency so the 2nd work tree is for something like an integration test.

As I work on my main worktree, I discover that I would like to add more logs in the unit tests to figure out what might be wrong. I also think that these logs would be good in the integration tests as well and would like to update my worktree with the most recent changes in main.

Is there a way to update the integration worktree with something similar to git pull from main? Something that would look like git worktree pull? If not, is there a workaround as I don't see anything remotely like it in the docs?

I don't like the idea of creating a new worktree every time I could have done something like git worktree pull.

NOTE: I don't want to commit changes just yet because nothing is confirmed as working correctly.

I didn't undestand what this user is trying to do here and I am not working with submodules.

Answer 1

I recommend using git diff and git apply

git diff creates a "diff file" for your current worktree.
git apply applies a diff file to the current worktree

This is the best way to copy uncommitted changes from one worktree to another.

Example:

cd /git/main 
git diff > /path/to/difffile
cd /git/integration
git apply /path/to/difffile

Note: You can also specify the files you want to include in the diff, if you do not want to copy the changes from all files, only some:

git diff -- file1 subdir/file2 > /path/to/difffile

Answer 2

NOTE: I don't want to commit changes just yet because nothing is confirmed as working correctly.

That is fine. You can just commit it—commits are not just for working code.

Commits are like the first-class citizens of Git. Once something is committed you can do most of what you want to do with what one might broadly call changes:

• Put it on another branch (git-cherry-pick(1))
• Put it and other commits on another branch (git-rebase(1))
• Find when you made the commit with git-reflog(1)
• Toss away the commit and keep the changes (like return it to the staging area) with git-reset(1)

But until you commit it they are just changes in your working tree in one of your worktrees and your options are more limited.

I don't like the idea of creating a new worktree every time I could have done something like git worktree pull.

The goal of using a separate worktree seems to be about getting a different executable. That makes sense when you are working on something very different from “main” which might take a while to build. But whether those changes (relative to main) are in a commit or in the staging area or something else doesn't matter as far as the build is concerned.

So I would use commits and then for example cherry-pick them to wherever you need them.

The purpose of worktrees

heretoinfinity asked about the purpose of using worktrees. I surmised that the goal here was to build different executables. For example, in my own work I sometimes have to build and deploy something to a server. For that I might have a worktree called deploy-dayjob-repo. The benefit of that is that I can start the build in that worktree and then work on something else in another worktree; I won't have to worry about interfering with the build by making changes or changing branches, since my worktree doesn't interfere with the deploy-dayjob-repo worktree. But keep in mind that this extra step is optional. If, say, the build and deploy only took a little while I might have not used a separate worktree for that. Or I might have waited for it to complete and gotten a cup of coffee/tea.

On the purpose and uses of worktrees in general I have written about it here. See also the other answers on that question.