Re: submodules and merging (Was: Re: [PATCH 02/30] merge-recursive: Fix logic ordering issue)
- From
Jacob Keller <jacob.keller@gmail.com>
- Date
- Nov 26, 2017, 05:59 UTC
- Message-ID
- <CA+P7+xonU838dOAzsUY4KmweYyM-NLFQeKVYD9jYM7i5EuWXcw@mail.gmail.com>
- In-Reply-To
- <CABPp-BFdJr8AL3hJSSLiqwPJMt6LZcLOEcTtxz1vohEuw==wKg@mail.gmail.com>
On Sat, Nov 25, 2017 at 2:37 PM, Elijah Newren <newren@gmail.com> wrote:
Show 21 quoted lines
> 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.
I agree, that is absolutely a (big) step in the right direction.
Thanks, Jake