git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Kyle Zhao via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Kyle Zhao <kylezhao@tencent.com>
Subject: Re: [PATCH] merge-tree.c: add --merge-base=<commit> option
Date: Fri, 28 Oct 2022 09:03:50 -0700	[thread overview]
Message-ID: <xmqqfsf8j5p5.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BHceBeo6Y8s00gET=4yqCMf3qqsiNMhqJ34HVf8r=bhnw@mail.gmail.com> (Elijah Newren's message of "Fri, 28 Oct 2022 01:20:18 -0700")

Elijah Newren <newren@gmail.com> writes:

> On Thu, Oct 27, 2022 at 11:09 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
> [...]
>> Wouldn't it be sufficient to update the UI to
>>
>>     git merge-tree [--write-tree] [<options>] [<base-commit>] <branch1> <branch2>
>>     git merge-tree [--trivial-merge] <base-commit> <branch1> <branch2>
>>
>> IOW, when you want to supply the base, you'd be explicit and ask for
>> the new "write-tree" mode, i.e.
>>
>>     $ git merge-tree --write-tree $(git merge-base branch^ branch) HEAD branch
>>
>> would be how you would use merge-tree to cherry-pick the commit at
>> the tip of the branch on top of the current commit.
>
> This was my thought too; but would we be painting ourselves into a
> corner if we ever want to make merge-tree support octopus merges?

True, the above suggestion was especially bad as it would not be
possible to extend to support multiple bases *and* octopus at the
same time.  Consider it scrapped.  Taking zero or more --base-commit
options explicitly from the command line would be a better
interface.

> Also, why did you write $(git merge-base branch^ branch) rather than
> just branch^ ?

Just to be explicit which one is doing what.

> Yeah, I don't think that'd be too hard...if we could rule out ever
> supporting octopus merges in merge-tree (which I'm not so sure is a
> good assumption).  Otherwise, we might need to figure out the
> appropriate backward-compatible input parsing (and output format
> changes?)

I'd prefer an approach to tackle one thing at a time while making
sure we leave the door open for the future ones.  I think the
backend interface from "merge" to external strategies use a
separator to signal the boundary between the heads being merged
(i.e. branchN above) and the bases being used, which is easy to
parse and support multiple bases and octopus at the same time.

As to making it easy to implement "cherry-pick", I do not think you
should dogmatically forbid it on the basis for merge-tree from the
command line is inherently one mergy operation per invocation.  You
will have the --stdin interface, and a way forward may be a notation
to refer to previous results in the --stdin input stream.  That way,
a single invocation of merge-tree "server" can be fed a sequence of
3-way merges that are actually steps of multi-commit cherry-pick,
that merge the differences of multiple commits on top of the
previous result, one step at a time.

IOW, as long as you make sure --stdin interface is rich enough to
allow you do what people would do a sequence of "git merge-tree"
single shot invocations (perhaps even driven by a script), you would
be OK, I would think.


  reply	other threads:[~2022-10-28 16:05 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 12:12 [PATCH] merge-tree.c: add --merge-base=<commit> option Kyle Zhao via GitGitGadget
2022-10-27 18:09 ` Junio C Hamano
2022-10-28  8:20   ` Elijah Newren
2022-10-28 16:03     ` Junio C Hamano [this message]
2022-10-29  1:52       ` Elijah Newren
2022-10-28 11:43   ` [Internet]Re: " kylezhao(赵柯宇)
2022-10-28  8:13 ` Elijah Newren
2022-10-28 11:54   ` [Internet]Re: " kylezhao(赵柯宇)
2022-10-28 11:55 ` [PATCH v2] " Kyle Zhao via GitGitGadget
2022-10-29  1:32   ` Elijah Newren
2022-10-29  3:42   ` [PATCH v3] " Kyle Zhao via GitGitGadget
2022-11-01  1:08     ` Elijah Newren
2022-11-01  8:55     ` [PATCH v4 0/2] merge-tree: allow specifying a base commit when --write-tree is passed Kyle Zhao via GitGitGadget
2022-11-01  8:55       ` [PATCH v4 1/2] merge-tree.c: add --merge-base=<commit> option Kyle Zhao via GitGitGadget
2022-11-01  8:55       ` [PATCH v4 2/2] merge-tree.c: support --merge-base in conjunction with --stdin Kyle Zhao via GitGitGadget
2022-11-03  1:13         ` Elijah Newren
2022-11-03  3:28           ` [Internet]Re: " kylezhao(赵柯宇)
2022-11-01 21:19       ` [PATCH v4 0/2] merge-tree: allow specifying a base commit when --write-tree is passed Taylor Blau
2022-11-03  3:29       ` [PATCH v5 " Kyle Zhao via GitGitGadget
2022-11-03  3:29         ` [PATCH v5 1/2] merge-tree.c: add --merge-base=<commit> option Kyle Zhao via GitGitGadget
2022-11-03  8:36           ` Ævar Arnfjörð Bjarmason
2022-11-03  9:43             ` [Internet]Re: " kylezhao(赵柯宇)
2022-11-03  3:29         ` [PATCH v5 2/2] merge-tree.c: allow specifying the merge-base when --stdin is passed Kyle Zhao via GitGitGadget
2022-11-03 10:50         ` [PATCH v6 0/2] merge-tree: allow specifying a base commit when --write-tree " Kyle Zhao via GitGitGadget
2022-11-03 10:50           ` [PATCH v6 1/2] merge-tree.c: add --merge-base=<commit> option Kyle Zhao via GitGitGadget
2022-11-03 10:50           ` [PATCH v6 2/2] merge-tree.c: allow specifying the merge-base when --stdin is passed Kyle Zhao via GitGitGadget
2022-11-11 19:44             ` Elijah Newren
2022-11-11 23:45           ` [PATCH v7 0/2] merge-tree: allow specifying a base commit when --write-tree " Kyle Zhao via GitGitGadget
2022-11-11 23:45             ` [PATCH v7 1/2] merge-tree.c: add --merge-base=<commit> option Kyle Zhao via GitGitGadget
2022-11-22  3:04               ` Junio C Hamano
2022-11-22  3:52                 ` [Internet]Re: " kylezhao(赵柯宇)
2022-11-22  4:28                   ` Junio C Hamano
2022-11-22  5:42                     ` Junio C Hamano
2022-11-22  7:47                       ` [Internet]Re: " kylezhao(赵柯宇)
2022-11-11 23:45             ` [PATCH v7 2/2] merge-tree.c: allow specifying the merge-base when --stdin is passed Kyle Zhao via GitGitGadget
2022-11-12  0:32             ` [PATCH v7 0/2] merge-tree: allow specifying a base commit when --write-tree " Elijah Newren
2022-11-13  4:53             ` Taylor Blau
2022-11-13  4:54               ` Taylor Blau
2022-11-24  3:37             ` [PATCH v8 0/3] " Kyle Zhao via GitGitGadget
2022-11-24  3:37               ` [PATCH v8 1/3] merge-tree.c: add --merge-base=<commit> option Kyle Zhao via GitGitGadget
2022-11-24  3:37               ` [PATCH v8 2/3] merge-tree.c: allow specifying the merge-base when --stdin is passed Kyle Zhao via GitGitGadget
2022-11-24  3:37               ` [PATCH v8 3/3] docs: fix description of the `--merge-base` option Kyle Zhao via GitGitGadget
2022-11-25  5:28                 ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqfsf8j5p5.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=kylezhao@tencent.com \
    --cc=newren@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).