git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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...

  reply	other threads:[~2021-03-04 16:30 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

  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=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.
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).