At work, we use a lot of submodules (several levels of submodules actually).
As we also work with development branches, we use scripts to resync the whole 
checked-out tree (mainly in automated integration)

We recently run across an issue where a branch (dev) contained a submodule 
while it had been removed in master and the files were imported in a 
subdirectory with the same name (probably using git-subtree).


On dev:
* top/refs(submodule)/file1
On master:
* top/refs(dir)/file1

Outside the fact that it is quite hard to move from one branch to the other 
while having a perfectly clean tree checked out underneath, we manage to end up 
into a weird (invalid) state
that was neither clearly described nor "easy" to cleanup (using standard git 
clean/checkout/reset commands).

While I cannot explain how we got in this state, here is a small test-case that 
produce the same results:
mkdir folder1
cd folder1
git init
echo "Ooops" > file
git add file
git commit -m "Add file"
cd ..
mkdir folder2
cd folder2
git init
mkdir folder1
echo "Ooops" > folder1/file
git add folder1/file
git commit -m "Add file again"
git checkout -b branch
cp -R ../folder1/.git ./folder1
The 'cp' just seems pointless but with the submodule described as above we 
manage to end up in a similar state.
In this state, when being in folder2, git status reports nothing. Dev branch is 
checked out and everything looks great.

However if you change dir to folder2/folder1, while still being inside folder2, 
git thinks (because of the .git dir) that you are actually on master branch of 
folder1 repository.
Which mean that if you happen to commit from a subdirectory, you may easily 
end-up committing in another repository than the one expected.

The issue is, there is no way from folder2 to see that something "wrong" is 
going on inside your tree!
As we manage to reach this state using only standard git commands (I'll try to 
reproduce it) with submodules, and this being part of an automated flow, it is 
quite worrying.
We may actually be committing in the wrong repo and pushing the wrong things 

Is there or should there be a way to look for such issues? And is this an 
expected behaviour?

Thanks in advance


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to