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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 25, 2017 at 2:37 PM, Elijah Newren <newren@xxxxxxxxx> wrote:
> On Wed, Nov 15, 2017 at 9:13 AM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote:
>> On Tue, Nov 14, 2017 at 10:13 AM, Stefan Beller <sbeller@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx/
>
> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux