Hi,
We got at work a surprising error when trying to checkout a more recent
branch :
error: Untracked working tree file '(file)' would be overwritten by
merge. (I replaced the actual file name by 'file' in this mail)
The context is :
- Each developer has its own git repository, and makes all developement
work in it
- We use a "central" git repository to gather all our work, all devs
track this common repository's branches to pull and push they work.
- We don't allow devs to track another dev branch, everything must pass
by this central repository.
- We use git v 1.5.5.4, tig and git gui.
- Our main branch is called "trunk", and we use several other branches
for our work.
Last Thursday, I had to replace 6 directories (with files in them) by
symbolic links to another directory, in the "trunk" branch.
I removed them using sh rm -rf, then ln -s to create the links. Problem,
git gui failed to stage the changes to a single commit.
I split the change into 2 operations : the directory removal -> commit,
then the symlink creation -> commit.
I pushed the 2 commits - and other commits after - into our central
repository, no error was prompted.
Then came the issue :
Each time a dev tried to checkout the trunk branch from an older version
(e.g. a branch that has its origin to an older commit of trunk), he got
the error message
error: Untracked working tree file '(file)' would be overwritten by merge.
=> Checkout failed, etc. Obliged to force the checkout with git checkout -f.
- The file listed in the error message is absolutely not affected by any
commit in the 2 I mentioned above, nor in the 10 surrounding them. It
was not even changed for 2 monthes.
- The error occur even if we don't have any "modified" file (git status
answers nothing to commit, nor any untracked files)
- After investigations, it seems that the error occurs each time we ask
git to run the 2 commits mentioned above in a single checkout command :
If I checkout a branch pointing to the 1st commit (dir deletion), then
another checkout to the trunk head, the error does not occur.
- The file mentioned in the error is the first file in the directory
that follow the parent dir of the removed dirs (in the order returned by
ls):
- I failed to reproduce this bug using clean repositories...
Has anyone got this error before ?
Is it a git bug ?
Thanks for all
Swanny
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html