On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > You could try this patch series: > https://github.com/jlehmann/git-submod-enhancements/tree/git-checkout-recurse-submodules > (rebased to a newer version; no functional changes:) > https://github.com/stefanbeller/git/tree/submodule-co > (I'll rebase that later to origin/master) > >> >> Do you have any info on how I can prevent that error? Ideally I want >> the integration to go smoothly and transparently, not just for the >> person doing the actual transition (me) but for everyone else that >> gets those changes from upstream. They should not even notice that it >> happened (i.e. no failed commands, awkward behavior, or manual steps). > > It depends on how long you want to postpone the transition, but I plan to > upstream the series referenced above in the near future, > which would enable your situation to Just Work (tm). ;) At first glance, what you've linked to essentially looks like automated `git submodule update` for every `git checkout`. Am I misunderstanding? If I'm correct, this is not the same as what I'm talking about. The problem appears to be more internal: When a submodule is removed, the physical files that were there are not removed by Git. It leaves them there in the working copy as untracked files. The next step Git takes (again, just from outside observation) is to add those very same files to the working copy, since they were added to a commit. However, at this point Git fails because it's trying to create (write) files to the working copy when an exact file of that name already exists there. Git will not overwrite untracked files, so at this point it fails. What needs to happen, somehow, is Git sees that the files were actually part of a submodule (which was removed) and remove the physical files as well, assuming that they were not modified in the submodule itself. This will ensure that the next step (creating the files) will succeed since the files no longer block it.