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

From: Elijah Newren <newren@gmail.com>
Date: Nov 25, 2017, 22:37 UTC
Message-ID: <CABPp-BFdJr8AL3hJSSLiqwPJMt6LZcLOEcTtxz1vohEuw==wKg@mail.gmail.com>
In-Reply-To: <CA+P7+xorpJGrn=5zTrAPVDwHLkU5vCphOrebkH_d+MxV1k1oRg@mail.gmail.com>

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:

Show 11 quoted lines

>> 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.