mailing list mirror (one of many)
 help / Atom feed
From: Stefan Beller <>
To: Jacob Keller <>
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 11:33:28 -0800
Message-ID: <> (raw)
In-Reply-To: <>

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.


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


  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 [this message]
2017-12-04 20:16           ` Jacob Keller

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

* 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