All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] merge-tree: accept 3 trees as arguments
Date: Fri, 26 Jan 2024 08:01:38 -0800	[thread overview]
Message-ID: <xmqqplxoozh9.fsf@gitster.g> (raw)
In-Reply-To: <pull.1647.git.1706277694231.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Fri, 26 Jan 2024 14:01:34 +0000")

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> When specifying a merge base explicitly, there is actually no good
> reason why the inputs need to be commits: that's only needed if the
> merge base has to be deduced from the commit graph.

yes, Yes, YES, YEAHHHHH!

>     I was asked to implement this at $dayjob and it seems like a feature
>     that might be useful to other users, too.

Yup, I think it is an obvious building block for machinery to
perform any mergy operation to grow history.  Many of the time you
may have a commit, but requiring them to be commits when you know
you will not do a virtual ancestor synthesis smells fundamentally
wrong.  Thanks for fixing it.

> ---merge-base=<commit>::
> +--merge-base=<tree-ish>::
>  	Instead of finding the merge-bases for <branch1> and <branch2>,
>  	specify a merge-base for the merge, and specifying multiple bases is
>  	currently not supported. This option is incompatible with `--stdin`.
> ++
> +As the merge-base is provided directly, <branch1> and <branch2> do not need
> +o specify commits; it is sufficient if they specify trees.

"... do not need to specify commits; trees are enough"?

> diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
> index 3bdec53fbe5..cbd8e15af6d 100644
> --- a/builtin/merge-tree.c
> +++ b/builtin/merge-tree.c
> @@ -429,35 +429,43 @@ static int real_merge(struct merge_tree_options *o,
>  	struct merge_options opt;
>  
>  	copy_merge_options(&opt, &o->merge_options);
> -	parent1 = get_merge_parent(branch1);
> -	if (!parent1)
> -		help_unknown_ref(branch1, "merge-tree",
> -				 _("not something we can merge"));
> -
> -	parent2 = get_merge_parent(branch2);
> -	if (!parent2)
> -		help_unknown_ref(branch2, "merge-tree",
> -				 _("not something we can merge"));
> -
>  	opt.show_rename_progress = 0;
>  
>  	opt.branch1 = branch1;
>  	opt.branch2 = branch2;
>  
>  	if (merge_base) {
> -		struct commit *base_commit;
>  		struct tree *base_tree, *parent1_tree, *parent2_tree;
>  
> -		base_commit = lookup_commit_reference_by_name(merge_base);
> -		if (!base_commit)
> -			die(_("could not lookup commit '%s'"), merge_base);
> +		/*
> +		 * We actually only need the trees because we already
> +		 * have a merge base.
> +		 */
> +		struct object_id base_oid, head_oid, merge_oid;
> +
> +		if (repo_get_oid_treeish(the_repository, merge_base, &base_oid))
> +			die(_("could not parse as tree '%s'"), merge_base);
> +		base_tree = parse_tree_indirect(&base_oid);
> +		if (repo_get_oid_treeish(the_repository, branch1, &head_oid))
> +			die(_("could not parse as tree '%s'"), branch1);
> +		parent1_tree = parse_tree_indirect(&head_oid);
> +		if (repo_get_oid_treeish(the_repository, branch2, &merge_oid))
> +			die(_("could not parse as tree '%s'"), branch2);
> +		parent2_tree = parse_tree_indirect(&merge_oid);
>  
>  		opt.ancestor = merge_base;
> -		base_tree = repo_get_commit_tree(the_repository, base_commit);
> -		parent1_tree = repo_get_commit_tree(the_repository, parent1);
> -		parent2_tree = repo_get_commit_tree(the_repository, parent2);
>  		merge_incore_nonrecursive(&opt, base_tree, parent1_tree, parent2_tree, &result);
>  	} else {
> +		parent1 = get_merge_parent(branch1);
> +		if (!parent1)
> +			help_unknown_ref(branch1, "merge-tree",
> +					 _("not something we can merge"));
> +
> +		parent2 = get_merge_parent(branch2);
> +		if (!parent2)
> +			help_unknown_ref(branch2, "merge-tree",
> +					 _("not something we can merge"));
> +
>  		/*
>  		 * Get the merge bases, in reverse order; see comment above
>  		 * merge_incore_recursive in merge-ort.h

OK.  The changes here look quite straight-forward.

> diff --git a/t/t4301-merge-tree-write-tree.sh b/t/t4301-merge-tree-write-tree.sh
> index 12ac4368736..71f21bb834f 100755
> --- a/t/t4301-merge-tree-write-tree.sh
> +++ b/t/t4301-merge-tree-write-tree.sh
> @@ -945,4 +945,12 @@ test_expect_success 'check the input format when --stdin is passed' '
>  	test_cmp expect actual
>  '
>  
> +test_expect_success '--merge-base with tree OIDs' '
> +	git merge-tree --merge-base=side1^ side1 side3 >tree &&
> +	tree=$(cat tree) &&
> +	git merge-tree --merge-base=side1^^{tree} side1^{tree} side3^{tree} >tree2 &&
> +	tree2=$(cat tree2) &&
> +	test $tree = $tree2
> +'

You do not need $tree and $tree2 variables that would make it harder
to diagnose a failure case when we break merge-tree.  You have tree
and tree2 as files, and I think it is sufficient to do

	git merge-tree ... >result-from-commits &&
	git merge-tree ... >result-from-trees &&
	test_cmp result-from-commits result-from-trees

(no, I am not suggesting to rename these tree and tree2 files; I
just needed them to be descriptive in my illustration to show what
is going on to myself).

Thanks.

  parent reply	other threads:[~2024-01-26 16:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26 14:01 [PATCH] merge-tree: accept 3 trees as arguments Johannes Schindelin via GitGitGadget
2024-01-26 14:15 ` Eric Sunshine
2024-01-26 16:01 ` Junio C Hamano [this message]
2024-01-30 20:05   ` Johannes Schindelin
2024-01-28 20:34 ` [PATCH v2] " Johannes Schindelin via GitGitGadget
2024-01-29 17:49   ` Junio C Hamano
2024-01-30  7:04 ` [PATCH] " Elijah Newren
2024-01-30 17:15   ` Junio C Hamano
2024-01-31 16:34     ` Elijah Newren
2024-01-31 18:14       ` Junio C Hamano
2024-01-30 20:04   ` Johannes Schindelin
2024-01-31 16:40     ` Elijah Newren

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=xmqqplxoozh9.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    /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.