All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Christian Couder <christian.couder@gmail.com>,
	ZheNing Hu <adlternative@gmail.com>,
	Git List <git@vger.kernel.org>,
	vascomalmeida@sapo.pt
Subject: Re: Question about pre-merge and git merge octopus strategy
Date: Sat, 07 May 2022 11:37:13 -0700	[thread overview]
Message-ID: <xmqq8rrdgpeu.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BGD3AZvXwmSHfQQ_xh_UqevH23kdBYijAWUk8GHu1q0Qw@mail.gmail.com> (Elijah Newren's message of "Fri, 6 May 2022 21:09:45 -0700")

Elijah Newren <newren@gmail.com> writes:

> However, I think Junio said that octopus merge only handles trivial
> cases anyway,...

"git merge -s octopus A B C" deliberately made a design decision to
strongly discourage the users from creating an octopus that requires
non-trivial merges.  One of the reasons is because octopus merges
make the history less efficient to bisect, and they are meant as a
way to bind totally unrelated changes, whose order of merging into
the resulting history does not matter.

Yes, it is an opinionated design choice, but "git merge" is a
Porcelain that can afford to be opinionated.  It also means that
tools other than the git-merge--octopus backend does not have to
follow the design philosophy.

> ... in which case an iterated "git merge --write-tree" would
> actually be a sufficient solution here and we could sidestep the more
> convoluted cases.  But, sadly for ZheNing, that option doesn't exist
> yet -- It's still under development.

  reply	other threads:[~2022-05-07 18:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06  8:14 Question about pre-merge and git merge octopus strategy ZheNing Hu
2022-05-06 17:23 ` Christian Couder
2022-05-07  4:09   ` Elijah Newren
2022-05-07 18:37     ` Junio C Hamano [this message]
2022-05-08 14:44     ` ZheNing Hu
2022-05-10  7:07       ` Elijah Newren
2022-05-11 11:21         ` ZheNing Hu
2022-05-12 15:04           ` Elijah Newren
2022-05-12 15:39             ` Junio C Hamano
2022-05-13  5:15               ` Elijah Newren
2022-05-13 12:56                 ` Junio C Hamano
2022-05-19 13:15                 ` ZheNing Hu
2022-05-19 14:46                   ` Elijah Newren
2022-05-08 14:13   ` ZheNing Hu
2022-05-08 15:01 ` Carlo Marcelo Arenas Belón

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=xmqq8rrdgpeu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=adlternative@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=vascomalmeida@sapo.pt \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.