On Fri, Sep 9, 2016 at 4:37 PM, Dakota Hawkins <dakotahawk...@gmail.com> wrote: > Any ideas on this anywhere? > > In my opinion if a merge can fast-forward without conflict it should > trivially be able to non-fast-forward without conflict.
Yes, I agree. Though the submodules still have a lot of sharp edges that you can injure yourself with. I am sorry to let you down here, but I did not have time and mental capacity to actually dive into the issue further this week. I hoped someone else would have picked up this thread and have a good idea. 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 plan to fix that in the near future (read: teach git checkout to know about submodules), mind that there is already a patch series for exactly that out there in one of the branches of https://github.com/jlehmann/git-submod-enhancements This seems to be not an easy fix; Someone tried already and getting it polished enough to include it upstream was not successful. > > 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. Thanks, Stefan
