> As you know currently the checkout doesn't touch submodules, i.e. > you have to run "git submodule update" whenever the submodule > changes. So when you checkout a different part of history, that moved > a submodule, this will fail as the submodule still resides at the old > place (and may have path name conflict with another thing) > and is not there at the new place.
I _think_ (may be wrong) that you can reproduce this without ever updating the submodules at all. I may be missing/forgetting something in my config: I normally have global post-checkout and post-merge hooks to run a submodule update, however I realized that and (I think) disabled them for the second more concise reproduction I sent. I moved them to a "no" subdirectory in my hook directory -- git doesn't recursively look for hooks, does it? Anyway, I don't think that's a difference in my case. It may be, I agree, if you happen to be reproducing this issue locally in your working repository for some reason. That thought process makes sense to me because as I mentioned initially these failures presented on our remote (bitbucket server, if it matters) for a pull-request merge. I don't know for certain but I don't believe the server's copy of the repo would need to update the submodules at all, ever. >> >> Also, I'm not too familiar/comfortable with mailing list etiquette, >> and I don't want to be a bother by continuing to ping this thread. > > Pinging is fine, as it is rather easy to ignore mails on a mailing list. ;) > I just don't know if it increases likelihood of someone responding. Apparently it got you on the hook! Thanks for taking the bait :) Dakota
