Re: submodules and merging (Was: Re: [PATCH 02/30] merge-recursive: Fix logic ordering issue)

[Stefan Beller <sbeller@google.com>]

On Sat, Nov 25, 2017 at 9:59 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Sat, Nov 25, 2017 at 2:37 PM, Elijah Newren <newren@gmail.com> wrote:
>> On Wed, Nov 15, 2017 at 9:13 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>> On Tue, Nov 14, 2017 at 10:13 AM, Stefan Beller <sbeller@google.com> wrote:
>>
>>>> But this line of though might be distracting from your original point,
>>>> which was that we have so much to keep in mind when doing tree
>>>> operations (flags, D/F conflicts, now submodules too). I wonder how
>>>> a sensible refactoring would look like to detangle all these aspects,
>>>> but still keeping Git fast and not overengineered.
>>>
>>> I think given how complex a lot of these code paths are, that an
>>> attempt to refactor it a bit to detangle some of the mess would be
>>> well worth the time. I'd suspect it might make handling the more
>>> complex task of actually resolving conflicts to be easier, so the
>>> effort to clean up the code here should be worth it.
>>
>> I think changing from a 4-way merge to a 3-way merge would make things
>> much better, as Junio outlined here:
>>
>> https://public-inbox.org/git/xmqqd147kpdm.fsf@gitster.mtv.corp.google.com/
>>
>> I don't know of any way to detangle the other aspects, yet.

Jonathan Nieder and me tried some pair programming some time ago[1]
plumbing the repository object through most of the low level internals, which
would help in detangling submodule merges as then these merges could
be done in-core, just as Junio laid out.

[1] https://github.com/stefanbeller/git/tree/object-store-jrn-rebased

> I agree, that is absolutely a (big) step in the right direction.


I agree as well; A better (abstracted) merge backend would be huge for
the future of Git.

Thanks,
Stefan