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.