Re: [PATCH v6 2/2] merge-tree.c: allow specifying the merge-base when --stdin is passed
- From
Elijah Newren <newren@gmail.com>
- Date
- Nov 11, 2022, 19:44 UTC
- Message-ID
- <CABPp-BFgjT7b5EyVU7P4YpGvGZk9xfV+nDJG2UBtGc2c3VqeFw@mail.gmail.com>
- In-Reply-To
- <40d56544e6e319605d02bab743a6e957ff0a5926.1667472621.git.gitgitgadget@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.
Show 25 quoted lines
> + > +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/