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

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.


Reply via email to