On Wed, Oct 19, 2016 at 2:51 PM, Robert Dailey <rcdailey.lists@xxxxxxxxx> wrote: > 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? I'll assume (due to the lack of responses) that the only viable solution here is to integrate the submodule using a different directory name than the one used by the submodule itself. It's unfortunate but I'll do it if I have no other option.