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

From: Stefan Beller <sbeller@google.com>
Date: Sep 9, 2016, 23:57 UTC
Message-ID: <CAGZ79kapz7PR7vO2oyWE8WygXr+hTSJeZfZgpyeERv+Z1jTjCQ@mail.gmail.com>
In-Reply-To: <CAG0BQXmyW-Hzdyj4rTviToEVbJ73d94P9GcfFVR6P2XCsA2t-g@mail.gmail.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