From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>,
Elijah Newren <newren@gmail.com>
Subject: A merge-ort TODO comment, and how to test merge-ort?
Date: Thu, 04 Mar 2021 17:28:06 +0100 [thread overview]
Message-ID: <877dmmkhnt.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <69129a20edcfb57a3278285f31584ffcc2b3bad7.1609468488.git.gitgitgadget@gmail.com>
On Fri, Jan 01 2021, Elijah Newren via GitGitGadget wrote:
> + else {
> + /* must be the 100644/100755 case */
> + assert(S_ISREG(a->mode));
> + result->mode = a->mode;
> + clean = (b->mode == o->mode);
> + /*
> + * FIXME: If opt->priv->call_depth && !clean, then we really
> + * should not make result->mode match either a->mode or
> + * b->mode; that causes t6036 "check conflicting mode for
> + * regular file" to fail. It would be best to use some other
> + * mode, but we'll confuse all kinds of stuff if we use one
> + * where S_ISREG(result->mode) isn't true, and if we use
> + * something like 0100666, then tree-walk.c's calls to
> + * canon_mode() will just normalize that to 100644 for us and
> + * thus not solve anything.
> + *
> + * Figure out if there's some kind of way we can work around
> + * this...
> + */
So if tree-walk.c didn't call canon_mode() you would do:
if (opt->priv->call_depth && !clean)
result->mode = 0100666;
else
result->mode = a->mode;
I haven't looked at this bit closer, but that doesn't make the test
referenced here pass.
I'm refactoring tree-walk.h to do that in a WIP series, and ran into
this.
As an aside, how does one run the merge-ort tests in such a way as
they'll pass on master now? There's now a bunch of failures with
GIT_TEST_MERGE_ALGORITHM=ort, well, just for t*merge*.sh:
t6409-merge-subtree.sh (Wstat: 256 Tests: 12 Failed: 1)
Failed test: 12
Non-zero exit status: 1
t6418-merge-text-auto.sh (Wstat: 256 Tests: 10 Failed: 3)
Failed tests: 4-5, 10
Non-zero exit status: 1
t6437-submodule-merge.sh (Wstat: 0 Tests: 18 Failed: 0)
TODO passed: 13, 17
t6423-merge-rename-directories.sh (Wstat: 256 Tests: 68 Failed: 4)
Failed tests: 7, 53, 55, 59
Non-zero exit status: 1
And both test_expect_merge_algorithm and what seems to be a common
pattern of e.g.:
t6400-merge-df.sh: if test "$GIT_TEST_MERGE_ALGORITHM" = ort
t6400-merge-df.sh- then
t6400-merge-df.sh- test 0 -eq $(git ls-files -o | wc -l)
t6400-merge-df.sh- else
t6400-merge-df.sh- test 1 -eq $(git ls-files -o | wc -l)
t6400-merge-df.sh- fi &&
Will not run tests on both backends, I was expecting to find something
so we can the test N times for the backends, and declared if things were
to be skipped on ort or whatever.
I understand that this is still WIP code, but it would be nice to have
it in a state where one can confidently touch merge-ort.c when changing
some API or whatever and have it be tested by default.
Or maybe that's the case, and I've missed how it's happening...
next prev parent reply other threads:[~2021-03-04 16:29 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-18 5:51 [PATCH 00/10] merge-ort: add more handling of basic conflict types Elijah Newren via GitGitGadget
2020-12-18 5:51 ` [PATCH 01/10] merge-ort: handle D/F conflict where directory disappears due to merge Elijah Newren via GitGitGadget
2020-12-30 14:06 ` Derrick Stolee
2020-12-30 15:13 ` Elijah Newren
2020-12-31 11:17 ` Derrick Stolee
2020-12-31 17:13 ` Elijah Newren
2020-12-18 5:51 ` [PATCH 02/10] merge-ort: handle directory/file conflicts that remain Elijah Newren via GitGitGadget
2020-12-18 5:51 ` [PATCH 03/10] merge-ort: implement unique_path() helper Elijah Newren via GitGitGadget
2020-12-30 14:16 ` Derrick Stolee
2020-12-30 15:10 ` Elijah Newren
2020-12-31 11:19 ` Derrick Stolee
2020-12-18 5:51 ` [PATCH 04/10] merge-ort: handle book-keeping around two- and three-way content merge Elijah Newren via GitGitGadget
2020-12-18 5:51 ` [PATCH 05/10] merge-ort: flesh out implementation of handle_content_merge() Elijah Newren via GitGitGadget
2020-12-18 5:51 ` [PATCH 06/10] merge-ort: copy and adapt merge_3way() from merge-recursive.c Elijah Newren via GitGitGadget
2020-12-18 5:51 ` [PATCH 07/10] merge-ort: copy and adapt merge_submodule() " Elijah Newren via GitGitGadget
2020-12-18 5:51 ` [PATCH 08/10] merge-ort: implement format_commit() Elijah Newren via GitGitGadget
2020-12-18 5:51 ` [PATCH 09/10] merge-ort: copy find_first_merges() implementation from merge-recursive.c Elijah Newren via GitGitGadget
2020-12-18 5:51 ` [PATCH 10/10] merge-ort: add handling for different types of files at same path Elijah Newren via GitGitGadget
2020-12-29 0:44 ` [PATCH 00/10] merge-ort: add more handling of basic conflict types Elijah Newren
2021-01-01 2:34 ` [PATCH v2 " Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 01/10] merge-ort: handle D/F conflict where directory disappears due to merge Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 02/10] merge-ort: handle directory/file conflicts that remain Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 03/10] merge-ort: implement unique_path() helper Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 04/10] merge-ort: handle book-keeping around two- and three-way content merge Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 05/10] merge-ort: flesh out implementation of handle_content_merge() Elijah Newren via GitGitGadget
2021-03-04 16:28 ` Ævar Arnfjörð Bjarmason [this message]
2021-03-04 19:43 ` A merge-ort TODO comment, and how to test merge-ort? Elijah Newren
2021-03-04 21:29 ` Ævar Arnfjörð Bjarmason
2021-03-04 22:45 ` Elijah Newren
2021-03-08 14:49 ` Ævar Arnfjörð Bjarmason
2021-01-01 2:34 ` [PATCH v2 06/10] merge-ort: copy and adapt merge_3way() from merge-recursive.c Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 07/10] merge-ort: copy and adapt merge_submodule() " Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 08/10] merge-ort: implement format_commit() Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 09/10] merge-ort: copy find_first_merges() implementation from merge-recursive.c Elijah Newren via GitGitGadget
2021-01-01 2:34 ` [PATCH v2 10/10] merge-ort: add handling for different types of files at same path Elijah Newren via GitGitGadget
2021-01-05 14:23 ` [PATCH v2 00/10] merge-ort: add more handling of basic conflict types Derrick Stolee
2021-01-06 19:20 ` 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=877dmmkhnt.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@gmail.com \
--cc=stolee@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.
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.