From: Elijah Newren <newren@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
Matt Cree <matt.cree@gearset.com>,
git@vger.kernel.org, Elijah Newren <newren@gmail.com>
Subject: Re: Unexpected git merge exit code when killing merge driver during ancestor merge
Date: Wed, 8 May 2024 22:03:13 -0700 [thread overview]
Message-ID: <CABPp-BEogmpG7pYmC84WhQCy0tP97cV8BZ8epPeo4fzmRjU5Rg@mail.gmail.com> (raw)
In-Reply-To: <ZhBZOY1aEFW4YoD8@tapette.crustytoothpaste.net>
On Fri, Apr 5, 2024 at 1:04 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2024-04-04 at 16:16:05, Matt Cree wrote:
> > Hello all. I have observed some strange behaviour when exiting a custom merge driver that I was wondering if there’s any reason for — I think it may be a bug but I’ll leave that to you to decide.
> >
> > I’m configuring that merge driver to exit during a merge at the first sign of conflicts — the exact nature of the rules for the decision to exit early isn’t too important I think though so given it’s ‘work stuff’ I’ll leave some details out.
> >
> > Here is my current understanding of how the ort strategy will deal with this.
> >
> > - Ort runs the merge driver with the parameters for the current file to be merged
> > - When the driver returns exit code 0 is returned it is treated as having no conflicts
> > - When the driver returns exit code 1-128 is returned it is treated as having conflicts
> > - When the driver returns exit code 129+ is returned it is treated as some kind of error scenario
> >
> >
> > Then subsequently
> > - If all files returned exit code 0 during the merge git will return exit code 0 i.e. no conflicts
> > - If any file returned exit code 1-128 during the merge git will return exit code 1 i.e. conflicts
> > - At any time if the driver returns 129+, git will stop merging and return exit code 2 i.e. error?
> >
> > However, when setting up a criss-cross merge scenario and ‘short circuiting’ the merge during an ancestor merge, I get exit code 134
> >
> > Here’s a couple of quick scripts that help recreate the situation https://gist.github.com/mattcree/c6d8cc95f41e30b5d7467e9d2b01cd3d
>
> Thanks for the repro steps. I'm on Debian, which uses dash as /bin/sh,
> and I also use a different default branch (dev), so I was able to
> reproduce with the following patch applied:
>
> ----
> diff --git a/init-repo.sh b/init-repo.sh
> old mode 100644
> new mode 100755
> index e0f42a4..25d7f25
> --- a/init-repo.sh
> +++ b/init-repo.sh
> @@ -1,5 +1,5 @@
> rm -rf merge-driver-test
> mkdir merge-driver-test
> cd merge-driver-test
> -git init .
> +git init -b master .
> git commit --allow-empty -m "Initial"
> \ No newline at end of file
> diff --git a/run-merge.sh b/run-merge.sh
> old mode 100644
> new mode 100755
> diff --git a/run-recursive-merge.sh b/run-recursive-merge.sh
> old mode 100644
> new mode 100755
> index 6920720..c63d652
> --- a/run-recursive-merge.sh
> +++ b/run-recursive-merge.sh
> @@ -1,3 +1,5 @@
> +#!/bin/sh
> +
> cd merge-driver-test
>
> current_time=$(date "+%Y%m%d-%H%M%S");
> @@ -12,7 +14,7 @@ featureA="$current_time-feature-a";
> featureB="$current_time-feature-b";
> featureC="$current_time-feature-c";
>
> -function writeFiles() {
> +writeFiles() {
> cat > $xmlFileName << EOM
> <?xml version="1.0" encoding="UTF-8"?>
> <CustomLabels xmlns="http://soap.sforce.com/2006/04/metadata">
> ----
>
> I take it from the "Abort trap" message below, you're on macOS, but I
> don't think that's relevant to reproduction.
>
> > The logs also show
> >
> > ```
> > Assertion failed: (opt->priv == NULL), function merge_switch_to_result, file merge-ort.c, line 4661. ./run-recursive-merge.sh: line 162: 78797 Abort trap: 6 git merge $featureC --no-ff --no-commit
> > ```
>
> This is definitely a bug because we triggered an assertion. The
> assertion asserts that that case will never happen, so if it does, we've
> made a mistake in our code.
>
> This also explains the 134 exit status, because on most Unix systems,
> `SIGABRT` is signal 6, and when a program exits with a signal, the shell
> returns an exit status of 128 plus the signal number. Because a failed
> assertion calls `abort`, which raises `SIGABRT`, that would lead to an
> exit status in the shell of 134.
>
> I've CC'd Elijah Newren, who's the author of merge-ort and who wrote the
> code. I'm not familiar at all with merge-ort, so I can't speak to what
> might be going wrong here.
brian: Thanks for tagging me and expounding on the testcase.
Matt: sorry for taking so long to respond.
This is just a quick note to say I'm aware of the bug and will respond
(I think there might be a simple fix here), but for various reasons
it's going to be a couple more weeks.
next prev parent reply other threads:[~2024-05-09 5:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 16:16 Unexpected git merge exit code when killing merge driver during ancestor merge Matt Cree
2024-04-05 20:04 ` brian m. carlson
2024-05-09 5:03 ` Elijah Newren [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-05-08 18:14 Matt Cree
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=CABPp-BEogmpG7pYmC84WhQCy0tP97cV8BZ8epPeo4fzmRjU5Rg@mail.gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=matt.cree@gearset.com \
--cc=sandals@crustytoothpaste.net \
/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 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).