git-new-workdir: Commit in working tree A causes bogus changes in tree B

Question

I use git-new-workdir to have two working trees for one git repository. This usually works very well, but I get funny behaviour after committing something, if the same branch is checked out in both working trees:

• I start with both working trees clean and on "master".
• I commit something in working tree A.

Result:

• "git status" in working tree A shows "clean" (as expected)
• "git status" in working tree B suddenly shows "Changes to be committed"

The changes shown are the inverse of the commit I just made in A. For example, if the commit in A added a line, the "Changes to be committed" in B show that this line was removed.

What is happening here? Is this a known limitation of git-new-workdir? Is there a way to avoid this problem? Or should I just avoid checking in while the same branch is checked out in both copies?

I would also be interested in understanding what is happening here internally (I know little about git's internals).

Note:

I found that the problem is easy to resolve by just running git reset--hard in B, if B had no uncommitted changes prior to the commit in A.

However, if I commit in A while there are uncommitted changes in B, the real uncommitted changes get mixed with the bogus changes from the commit, and there seems to be no easy way to disentangle them. Hence the question.

Answer 1

I think this is the intended behavior. From http://nuclearsquid.com/writings/git-new-workdir/:

Create a new commit or branch in one of your working directories, they’re instantly available in all working directories.

When you commit a change in A, that commit is available to B as well. Since the line you just added in A isn't in B, it appears that you have made a change since the most recent commit.

I think the purpose of multiple working directories is to have different branches checked out at the same time.

Answer 2

As of 2015, this question is obsolete.

git-new-workdir has been superseded by git worktree (introduced in Git V2.5, July 2015). git worktree solves the problem described in this question by flatly refusing to check out the same branch in two worktrees:

$ git checkout myBranch
fatal: 'myBranch' is already checked out at '/tmp/otherworktree'