> 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

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 :)


Reply via email to