1

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.

heretoinfinity
  • 1,528
  • 3
  • 14
  • 33
  • 2
    A branch is a branch, isn't it? You can always merge one branch into another. "NOTE: I don't want to commit changes just yet because nothing is confirmed as working correctly." Well then there is no question to answer. In Git, commits are the only thing there is. So you've blocked yourself. – matt Aug 23 '23 at 14:04
  • `worktree`s allow you to copy uncommitted changes to oher places without commits so it is not much to ask to update just the worktree when uncommitted, unstaged changes can be moved around already – heretoinfinity Aug 23 '23 at 14:26
  • `git worktree pull` makes no sense since all worktrees work on the same repository—there is nothing to pull between worktrees. If you want to copy the unstaged changes from the `main` worktree to your own worktree then you should stop doing what you're doing and just make a branch for `integration` instead. – Guildenstern Aug 23 '23 at 15:20
  • "nothing is confirmed working": IMO if something is complete enough for you to desire to use it in an unrelated change, then it's worth commiting. Note that this doesn't mean that you need to push that change to your central repo, or that this individual commit ever needs to exist in the "real history" of the project, but you can just commit as "the log stuff" comment and when stuff **is** ready, you re-arrange stuff into a nice commit (or multiple) before pushing upstream. – Joachim Sauer Aug 31 '23 at 11:27
  • @JoachimSauer, I have never done the re-arranging before. How do you do this? The only way to avoid the issue that I can think of is to `Squash and Merge` the branch change. – heretoinfinity Sep 01 '23 at 20:05
  • 1
    @heretoinfinity: one simple way to do it is to check out the last commit, git reset soft to the last public commit, and then use `git add -p` to pick individual chunks to add (and then commit). This way you can build up a "fictional" history of your changes. Or just commit changes per-file, if that makes sense for your history. Or just compress it all down to one "do stuff" commit ... – Joachim Sauer Sep 01 '23 at 20:51

1 Answers1

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
David Sugar
  • 1,042
  • 6
  • 8