Re: [PATCH v6 2/2] merge-tree.c: allow specifying the merge-base when --stdin is passed

[Elijah Newren <newren@gmail.com>]

Sorry for the delay; my Git time has sadly been quite limited.  :-(

On Thu, Nov 3, 2022 at 3:50 AM Kyle Zhao via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> +# Since the earlier tests have verified that individual merge-tree calls
> +# are doing the right thing, this test case is only used to test whether
> +# the input format is available.

"the input format is available"?  I'm not sure exactly what that
means, but it seems almost certainly to not be the only thing it is
testing.  Perhaps you meant something like:

# Since the earlier tests have verified that individual merge-tree calls
# are doing the right thing, this test case is only used to verify that
# we can also trigger merges via --stdin, and that when we do we get
# the same answer as running a bunch of separate merges.

> +
> +test_expect_success 'check the input format when --stdin is passed' '
> +       test_when_finished "rm -rf repo" &&
> +       git init repo &&
> +       test_commit -C repo c1 &&
> +       test_commit -C repo c2 &&
> +       test_commit -C repo c3 &&
> +       printf "c1 c3\nc2 -- c1 c3\nc2 c3" | git -C repo merge-tree --stdin >actual &&
> +
> +       printf "1\0" >expect &&
> +       git -C repo merge-tree --write-tree -z c1 c3 >>expect &&
> +       printf "\0" >>expect &&
> +
> +       printf "1\0" >>expect &&
> +       git -C repo merge-tree --write-tree -z --merge-base=c2 c1 c3 >>expect &&
> +       printf "\0" >>expect &&
> +
> +       printf "1\0" >>expect &&
> +       git -C repo merge-tree --write-tree -z c2 c3 >>expect &&
> +       printf "\0" >>expect &&
> +
> +       test_cmp expect actual
> +'
> +
>  test_done

My above nit on your comment is my only remaining issue with your
implementation.  Looks good.

As an aside, I am still a little disappointed that the sole reason for
this series is limited to a usecase where this solution is at best an
interim hack[1][2]...but since I have had very limited time to work on
Git stuff including providing a proper solution for that usecase (in
the form of git-replay), and since it makes sense to include this
capability from a completeness perspective.

Anyway, thanks for patiently fixing everything up.  I think this
series should be ready to merge down once the comment is fixed up.

[1] https://lore.kernel.org/git/CABPp-BGBFyoY7m+KCA9MTifKmpZ0ccLgsYHahMCgPxuTpuUGPg@mail.gmail.com/
[2] https://lore.kernel.org/git/CABPp-BGXM=iRAgjNbZ0o3FSjj583GpkuFB6emUYwWjdFWb9-jQ@mail.gmail.com/