mailing list mirror (one of many)
 help / Atom feed
From: Jacob Keller <>
To: Stefan Beller <>
Cc: Elijah Newren <>, git <>
Subject: Re: submodules and merging (Was: Re: [PATCH 02/30] merge-recursive: Fix logic ordering issue)
Date: Mon, 4 Dec 2017 12:16:33 -0800
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Dec 4, 2017 at 11:33 AM, Stefan Beller <> wrote:
> On Sat, Nov 25, 2017 at 9:59 PM, Jacob Keller <> wrote:
>> On Sat, Nov 25, 2017 at 2:37 PM, Elijah Newren <> wrote:
>>> On Wed, Nov 15, 2017 at 9:13 AM, Jacob Keller <> wrote:
>>>> On Tue, Nov 14, 2017 at 10:13 AM, Stefan Beller <> 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:
>>> 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]

This sounds promising to me.


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

      reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-14 17:17 Elijah Newren
2017-11-14 18:13 ` Stefan Beller
2017-11-15 17:13   ` Jacob Keller
2017-11-25 22:37     ` Elijah Newren
2017-11-26  5:59       ` Jacob Keller
2017-12-04 19:33         ` Stefan Beller
2017-12-04 20:16           ` Jacob Keller [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox