-
Bug
-
Resolution: Obsolete
-
Low
-
None
-
1.3.3, 3.1.3
-
None
Step to reproduce:
- Have a git repo with a submodule checked out
- from another client, remove, commit and push the submodule removal
- from the first client, pull the changes (we have "Use rebase instead of merge by default for tracked branches" On here, not sure if it's relevant or not)
Expected result:
All the files of the submodule are gone if there is no uncommited/pushed change, a warning otherwise
Actual result:
The submodule is gone in SourceTree GUI, but the files are still present on disk. SourceTree does not suggest this files as new files for a commit. This files are hidden in the GUI
Also, the submodule data is still in .git\modules*, and cause trouble if you want to replace a submodule by another with the same name, or simply change the URL.
- is related to
-
SRCTREEWIN-937 Improve support for submodules
- Closed
[SRCTREEWIN-1330] SourceTree does not delete submodule files when pulling a submodule removal
That still affecting version (Mac) 1.8.1, actualy if the repository have more than 1 submodule and I delete one of them, the list of submodules don't shows anything, I guess the SourceTree is corrupting the submodules, by just changing the .gitmodules file.
May the correct steps to do is:
git submodule deinit asubmodule
git rm asubmodule
- Note: asubmodule (no trailing slash)
- or, if you want to leave it in your working tree
git rm --cached asubmodule
extracted from: http://stackoverflow.com/questions/1260748/how-do-i-remove-a-git-submodule
No, it's still a Git repo, all you do by removing it from the parent is remove the parent's own record of that git repo being referenced directly. You could just be doing that to move to a more flexible setup where you just maintain the submodule as a separate git repo in a dependencies folder without having any automatic / strong link between them. Deleting the .git folder would be too presumptuous of us, there are many reasons to remove a submodule so we do not stray beyond what git itself does in this case.
Michael Muré
added a comment - Not here to be a pain in the ass, but shouldn't SourceTree remove this .git folder, as it's not a git repo anymore ?
Michael Muré
added a comment - Not here to be a pain in the ass, but shouldn't SourceTree remove this .git folder, as it's not a git repo anymore ? They don't show in file status because they are inside a folder which itself has a .git folder, so it's a self-contained git repo in its own right. Git's own behaviour is to always ignore folders like that, because otherwise you'd have a recursive git repo! If you want to add those files verbatim, you should delete the nested .git repo, turning it into just a regular folder. Then the files will appear in the status window.
Michael Muré
added a comment - The idea is that you might have wanted to remove the record of the submodule, but that doesn't mean you wanted to remove the files (for example you might just have left the folder there as more loosely associated dependency, or maybe you wanted to use subtree). I don't think we would ever go against this convention.
Fair enough. But why are the file not showing as new files in "File status" ?
Michael Muré
added a comment - The idea is that you might have wanted to remove the record of the submodule, but that doesn't mean you wanted to remove the files (for example you might just have left the folder there as more loosely associated dependency, or maybe you wanted to use subtree). I don't think we would ever go against this convention.
Fair enough. But why are the file not showing as new files in "File status" ? Not deleting the underlying files when removing a submodule or switching to a commit which doesn't have this submodule is actually standard behaviour for git. The idea is that you might have wanted to remove the record of the submodule, but that doesn't mean you wanted to remove the files (for example you might just have left the folder there as more loosely associated dependency, or maybe you wanted to use subtree). I don't think we would ever go against this convention.
As for the submodule record still being in .git\modules, this is a nuance of submodule admin in git (changes in the working directory have to be synced to the internal git data), and this is something we should address.
Hi
This issue affects a version we no longer support. To avoid any ambiguity we feel it is better to explicitly close it rather than leave it un-resolved. However, if you feel the issue is still relevant then please do re-open this issue and update the "Affects Versions" field.
Thank you for using SourceTree.