Re: If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

[Stefan Beller <sbeller@google.com>]

On Fri, Sep 9, 2016 at 4:37 PM, Dakota Hawkins <dakotahawkins@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