On Wed, Oct 19, 2016 at 2:45 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > 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. It's great we're finally on the same page ;-) However, I don't see how this problem can be solved with your script, or solved in general outside of that. Does this mean that Git needs to change to treat submodules as it does normal files, per your previous assertion, which means submodules should *not* be left behind in the working copy as untracked files?