On Wed, Oct 19, 2016 at 12:19 PM, Robert Dailey <rcdailey.lists@xxxxxxxxx> wrote: > 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? Essentially yes, except with stricter rules than the actual submodule update IIRC. > > 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. That is also done by that series: submodules ought to be treated as files: If you checkout a new version where a file is deleted, the checkout command will actually remove the file for you (and e.g. solve any directory/file conflicts that may happen in the transition.) > It leaves them > there in the working copy as untracked files. That is the current behavior as checkout tries hard to ignore submodules. > 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. Yep.