Add merge recursive testcases with undetected conflicts
cover Add merge recursive testcases with undetected conflicts
SPOILER ALERT: This series contains answers to the "fun puzzle" at
https://public-inbox.org/git/CABPp-BFc1OLYKzS5rauOehvEugPc0oGMJp-NMEAmVMW7QR=4Eg@mail.gmail.com/
When a merge succeeds, we expect the resulting contents to depend only upon the trees and blobs of the branches involved and of their merge base(s). Unfortunately, there are currently about half a dozen cases where the contents of a "successful" merge depend on the relative commit timestamps of the merge bases. Document these with testcases.
(This series came out of looking at modifying how file collision conflict types are handled, as discussed at [1]. I discovered these issues while working on that topic.)
[1] https://public-inbox.org/git/CAPc5daVu8vv9RdGON8JiXEO3ycDVqQ38ySzZc-cpo+AQcAKXjA@mail.gmail.com/
Elijah Newren (6):
t6036: add a failed conflict detection case with symlink modify/modify
t6036: add a failed conflict detection case with symlink add/add
t6036: add a failed conflict detection case with submodule
modify/modify
t6036: add a failed conflict detection case with submodule add/add
t6036: add a failed conflict detection case with conflicting types
t6036: add a failed conflict detection case: regular files, different
modes
t/t6036-recursive-corner-cases.sh | 451 ++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+)
Signature · 1 line
2.18.0.130.gd703bbb5d
PATCH 1/6 t6036: add a failed conflict detection case with symlink modify/modify
--- t/t6036-recursive-corner-cases.sh | 67 +++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+)
t/t6036-recursive-corner-cases.sh +67 -0
@@ -805,4 +805,71 @@ test_expect_success 'virtual merge base handles rename/rename(1to2)/add-dest' ' ) ' +# +# criss-cross with modify/modify on a symlink: +# +# B D +# o---o +# / \ / \ +# A o X ? F +# \ / \ / +# o---o +# C E +# +# Commit A: simple simlink fickle->lagoon +# Commit B: redirect fickle->disneyland +# Commit C: redirect fickle->home +# Commit D: merge B&C, resolving in favor of B +# Commit E: merge B&C, resolving in favor of C +# +# This is an obvious modify/modify conflict for the symlink 'fickle'. Can +# git detect it? + +test_expect_success 'setup symlink modify/modify' ' + test_create_repo symlink-modify-modify && + ( + cd symlink-modify-modify && + + test_ln_s_add lagoon fickle && + git commit -m A && + git tag A && + + git checkout -b B A && + git rm fickle && + test_ln_s_add disneyland fickle && + git commit -m B && + + git checkout -b C A && + git rm fickle && + test_ln_s_add home fickle && + git add fickle && + git commit -m C && + + git checkout -q B^0 && + git merge -s ours -m D C^0 && + git tag D && + + git checkout -q C^0 && + git merge -s ours -m E B^0 && + git tag E + ) +' + +test_expect_failure 'check symlink modify/modify' ' + ( + cd symlink-modify-modify && + + git checkout D^0 && + + test_must_fail git merge -s recursive E^0 && + + git ls-files -s >out && + test_line_count = 3 out && + git ls-files -u >out && + test_line_count = 3 out && + git ls-files -o >out && + test_line_count = 1 out + ) +' + test_done
Signature · 1 line
2.18.0.130.gd703bbb5d
PATCH 2/6 t6036: add a failed conflict detection case with symlink add/add
In reply to Elijah Newren--- t/t6036-recursive-corner-cases.sh | 66 +++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+)
t/t6036-recursive-corner-cases.sh +66 -0
@@ -872,4 +872,70 @@ test_expect_failure 'check symlink modify/modify' ' ) ' +# +# criss-cross with add/add of a symlink: +# +# B D +# o---o +# / \ / \ +# A o X ? F +# \ / \ / +# o---o +# C E +# +# Commit A: No symlink or path exists yet +# Commit B: set up symlink: fickle->disneyland +# Commit C: set up symlink: fickle->home +# Commit D: merge B&C, resolving in favor of B +# Commit E: merge B&C, resolving in favor of C +# +# This is an obvious add/add conflict for the symlink 'fickle'. Can +# git detect it? + +test_expect_success 'setup symlink add/add' ' + test_create_repo symlink-add-add && + ( + cd symlink-add-add && + + touch ignoreme && + git add ignoreme && + git commit -m A && + git tag A && + + git checkout -b B A && + test_ln_s_add disneyland fickle && + git commit -m B && + + git checkout -b C A && + test_ln_s_add home fickle && + git add fickle && + git commit -m C && + + git checkout -q B^0 && + git merge -s ours -m D C^0 && + git tag D && + + git checkout -q C^0 && + git merge -s ours -m E B^0 && + git tag E + ) +' + +test_expect_failure 'check symlink add/add' ' + ( + cd symlink-add-add && + + git checkout D^0 && + + test_must_fail git merge -s recursive E^0 && + + git ls-files -s >out && + test_line_count = 2 out && + git ls-files -u >out && + test_line_count = 2 out && + git ls-files -o >out && + test_line_count = 1 out + ) +' + test_done
Signature · 1 line
2.18.0.130.gd703bbb5d
PATCH 3/6 t6036: add a failed conflict detection case with submodule modify/modify
In reply to Elijah Newren--- t/t6036-recursive-corner-cases.sh | 88 +++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)
t/t6036-recursive-corner-cases.sh +88 -0
@@ -938,4 +938,92 @@ test_expect_failure 'check symlink add/add' ' ) ' +# +# criss-cross with modify/modify on a submodule: +# +# B D +# o---o +# / \ / \ +# A o X ? F +# \ / \ / +# o---o +# C E +# +# Commit A: simple submodule repo +# Commit B: update repo +# Commit C: update repo differently +# Commit D: merge B&C, resolving in favor of B +# Commit E: merge B&C, resolving in favor of C +# +# This is an obvious modify/modify conflict for the submodule 'repo'. Can +# git detect it? + +test_expect_success 'setup submodule modify/modify' ' + test_create_repo submodule-modify-modify && + ( + cd submodule-modify-modify && + + test_create_repo submod && + ( + cd submod && + touch file-A && + git add file-A && + git commit -m A && + git tag A && + + git checkout -b B A && + touch file-B && + git add file-B && + git commit -m B && + git tag B && + + git checkout -b C A && + touch file-C && + git add file-C && + git commit -m C && + git tag C + ) && + + git -C submod reset --hard A && + git add submod && + git commit -m A && + git tag A && + + git checkout -b B A && + git -C submod reset --hard B && + git add submod && + git commit -m B && + + git checkout -b C A && + git -C submod reset --hard C && + git add submod && + git commit -m C && + + git checkout -q B^0 && + git merge -s ours -m D C^0 && + git tag D && + + git checkout -q C^0 && + git merge -s ours -m E B^0 && + git tag E + ) +' + +test_expect_failure 'check submodule modify/modify' ' + ( + cd submodule-modify-modify && + + git checkout D^0 && + + test_must_fail git merge -s recursive E^0 && + + git ls-files -s >out && + test_line_count = 3 out && + git ls-files -u >out && + test_line_count = 3 out && + git ls-files -o >out && + test_line_count = 1 out + ) +' + test_done
Signature · 1 line
2.18.0.130.gd703bbb5d
PATCH 4/6 t6036: add a failed conflict detection case with submodule add/add
In reply to Elijah Newren--- t/t6036-recursive-corner-cases.sh | 88 +++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)
t/t6036-recursive-corner-cases.sh +88 -0
@@ -1026,4 +1026,92 @@ test_expect_failure 'check submodule modify/modify' ' ) ' +# +# criss-cross with add/add on a submodule: +# +# B D +# o---o +# / \ / \ +# A o X ? F +# \ / \ / +# o---o +# C E +# +# Commit A: nothing of note +# Commit B: introduce submodule repo +# Commit C: introduce submodule repo at different commit +# Commit D: merge B&C, resolving in favor of B +# Commit E: merge B&C, resolving in favor of C +# +# This is an obvious add/add conflict for the submodule 'repo'. Can +# git detect it? + +test_expect_success 'setup submodule add/add' ' + test_create_repo submodule-add-add && + ( + cd submodule-add-add && + + test_create_repo submod && + ( + cd submod && + touch file-A && + git add file-A && + git commit -m A && + git tag A && + + git checkout -b B A && + touch file-B && + git add file-B && + git commit -m B && + git tag B && + + git checkout -b C A && + touch file-C && + git add file-C && + git commit -m C && + git tag C + ) && + + touch irrelevant-file && + git add irrelevant-file && + git commit -m A && + git tag A && + + git checkout -b B A && + git -C submod reset --hard B && + git add submod && + git commit -m B && + + git checkout -b C A && + git -C submod reset --hard C && + git add submod && + git commit -m C && + + git checkout -q B^0 && + git merge -s ours -m D C^0 && + git tag D && + + git checkout -q C^0 && + git merge -s ours -m E B^0 && + git tag E + ) +' + +test_expect_failure 'check submodule add/add' ' + ( + cd submodule-add-add && + + git checkout D^0 && + + test_must_fail git merge -s recursive E^0 && + + git ls-files -s >out && + test_line_count = 3 out && + git ls-files -u >out && + test_line_count = 2 out && + git ls-files -o >out && + test_line_count = 1 out + ) +' + test_done
Signature · 1 line
2.18.0.130.gd703bbb5d
PATCH 5/6 t6036: add a failed conflict detection case with conflicting types
In reply to Elijah Newren--- t/t6036-recursive-corner-cases.sh | 75 +++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+)
t/t6036-recursive-corner-cases.sh +75 -0
@@ -1114,4 +1114,79 @@ test_expect_failure 'check submodule add/add' ' ) ' +# +# criss-cross with conflicting entry types: +# +# B D +# o---o +# / \ / \ +# A o X ? F +# \ / \ / +# o---o +# C E +# +# Commit A: nothing of note +# Commit B: introduce submodule 'path' +# Commit C: introduce symlink 'path' +# Commit D: merge B&C, resolving in favor of B +# Commit E: merge B&C, resolving in favor of C +# +# This is an obvious add/add conflict for 'path'. Can git detect it? + +test_expect_success 'setup conflicting entry types (submodule vs symlink)' ' + test_create_repo submodule-symlink-add-add && + ( + cd submodule-symlink-add-add && + + test_create_repo path && + ( + cd path && + touch file-B && + git add file-B && + git commit -m B && + git tag B + ) && + + touch irrelevant-file && + git add irrelevant-file && + git commit -m A && + git tag A && + + git checkout -b B A && + git -C path reset --hard B && + git add path && + git commit -m B && + + git checkout -b C A && + rm -rf path/ && + test_ln_s_add irrelevant-file path && + git commit -m C && + + git checkout -q B^0 && + git merge -s ours -m D C^0 && + git tag D && + + git checkout -q C^0 && + git merge -s ours -m E B^0 && + git tag E + ) +' + +test_expect_failure 'check conflicting entry types (submodule vs symlink)' ' + ( + cd submodule-symlink-add-add && + + git checkout D^0 && + + test_must_fail git merge -s recursive E^0 && + + git ls-files -s >out && + test_line_count = 3 out && + git ls-files -u >out && + test_line_count = 2 out && + git ls-files -o >out && + test_line_count = 1 out + ) +' + test_done
Signature · 1 line
2.18.0.130.gd703bbb5d
PATCH 6/6 t6036: add a failed conflict detection case: regular files, different modes
In reply to Elijah Newren--- t/t6036-recursive-corner-cases.sh | 67 +++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+)
t/t6036-recursive-corner-cases.sh +67 -0
@@ -1189,4 +1189,71 @@ test_expect_failure 'check conflicting entry types (submodule vs symlink)' ' ) ' +# +# criss-cross with regular files that have conflicting modes: +# +# B D +# o---o +# / \ / \ +# A o X ? F +# \ / \ / +# o---o +# C E +# +# Commit A: nothing of note +# Commit B: introduce file source_me.bash, not executable +# Commit C: introduce file source_me.bash, executable +# Commit D: merge B&C, resolving in favor of B +# Commit E: merge B&C, resolving in favor of C +# +# This is an obvious add/add mode conflict. Can git detect it? + +test_expect_success 'setup conflicting modes for regular file' ' + test_create_repo regular-file-mode-conflict && + ( + cd regular-file-mode-conflict && + + touch irrelevant-file && + git add irrelevant-file && + git commit -m A && + git tag A && + + git checkout -b B A && + echo "export PATH=~/bin:$PATH" >source_me.bash && + git add source_me.bash && + git commit -m B && + + git checkout -b C A && + echo "export PATH=~/bin:$PATH" >source_me.bash && + git add source_me.bash && + test_chmod +x source_me.bash && + git commit -m C && + + git checkout -q B^0 && + git merge -s ours -m D C^0 && + git tag D && + + git checkout -q C^0 && + git merge -s ours -m E B^0 && + git tag E + ) +' + +test_expect_failure 'check conflicting modes for regular file' ' + ( + cd regular-file-mode-conflict && + + git checkout D^0 && + + test_must_fail git merge -s recursive E^0 && + + git ls-files -s >out && + test_line_count = 3 out && + git ls-files -u >out && + test_line_count = 2 out && + git ls-files -o >out && + test_line_count = 1 out + ) +' + test_done
Signature · 1 line
2.18.0.130.gd703bbb5d
Quoted 9 lines · Elijah Newren
SPOILER ALERT: This series contains answers to the "fun puzzle" at
https://public-inbox.org/git/CABPp-BFc1OLYKzS5rauOehvEugPc0oGMJp-NMEAmVMW7QR=4Eg@mail.gmail.com/When a merge succeeds, we expect the resulting contents to depend only upon the trees and blobs of the branches involved and of their merge base(s). Unfortunately, there are currently about half a dozen cases where the contents of a "successful" merge depend on the relative commit timestamps of the merge bases. Document these with testcases.
Quoted 3 lines
(This series came out of looking at modifying how file collision conflict types are handled, as discussed at [1]. I discovered these issues while working on that topic.)
I have a topic branch for this series but not merged to 'pu' as test-lint gives these:
t6036-recursive-corner-cases.sh:1222: error: "export FOO=bar" is not portable (please use FOO=bar && export FOO): echo "export PATH=~/bin:$PATH" >source_me.bash &&
t6036-recursive-corner-cases.sh:1227: error: "export FOO=bar" is not portable (please use FOO=bar && export FOO): echo "export PATH=~/bin:$PATH" >source_me.bash &&
Makefile:77: recipe for target 'test-lint-shell-syntax' failed
make: *** [test-lint-shell-syntax] Error 1
Arguably these are false positives because "source_me.bash" file is a mere payload to go through the merge process to be munged and we never intend to actually execute its contents with bash, but then the test payload probably does not even have to be a string that triggers such a false positive to begin with ;-)
Quoted 20 lines · Junio C Hamano
Quoted 9 lines · Elijah Newren
When a merge succeeds, we expect the resulting contents to depend only upon the trees and blobs of the branches involved and of their merge base(s). Unfortunately, there are currently about half a dozen cases where the contents of a "successful" merge depend on the relative commit timestamps of the merge bases. Document these with testcases.
(This series came out of looking at modifying how file collision conflict types are handled, as discussed at [1]. I discovered these issues while working on that topic.)
I have a topic branch for this series but not merged to 'pu' as test-lint gives these:
t6036-recursive-corner-cases.sh:1222: error: "export FOO=bar" is not portable (please use FOO=bar && export FOO): echo "export PATH=~/bin:$PATH" >source_me.bash &&
t6036-recursive-corner-cases.sh:1227: error: "export FOO=bar" is not portable (please use FOO=bar && export FOO): echo "export PATH=~/bin:$PATH" >source_me.bash &&
Makefile:77: recipe for target 'test-lint-shell-syntax' failed
make: *** [test-lint-shell-syntax] Error 1
Quoted 5 lines
Arguably these are false positives because "source_me.bash" file is a mere payload to go through the merge process to be munged and we never intend to actually execute its contents with bash, but then the test payload probably does not even have to be a string that triggers such a false positive to begin with ;-)
Oh, I didn't know about test-lint. Is there a place that documents the various checks you run, so I can avoid slowing you down? Ones I know about:
Already documented:
* make DEVELOPER=1 (from CodingGuidelines)
* running tests (from SubmittingPatches)
Stuff I've seen you mention in emails over time:
* linux/scripts/checkpatch.pl
* git grep -e '\<inline\>' --and --not -e 'static inline' -- \*.h
* make -C t/ test-lint
Are there others?
Also, here's a fixup to the topic; as you pointed out, the exact contents of the script being written were actually irrelevant; it was just an input to a merge.
-- 8< --
Subject: [PATCH] fixup! t6036: add a failed conflict detection case: regular
files, different modes
--- t/t6036-recursive-corner-cases.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
t/t6036-recursive-corner-cases.sh +2 -2
@@ -1219,12 +1219,12 @@ test_expect_success 'setup conflicting modes for regular file' ' git tag A && git checkout -b B A && - echo "export PATH=~/bin:$PATH" >source_me.bash && + echo "command_to_run" >source_me.bash && git add source_me.bash && git commit -m B && git checkout -b C A && - echo "export PATH=~/bin:$PATH" >source_me.bash && + echo "command_to_run" >source_me.bash && git add source_me.bash && test_chmod +x source_me.bash && git commit -m C &&
Signature · 1 line
2.18.0.135.gd4ea5491ab
Quoted 4 lines · Elijah Newren
Oh, I didn't know about test-lint. Is there a place that documents the various checks you run, so I can avoid slowing you down? Ones I know about:
Quoted 8 lines
Already documented:
*make DEVELOPER=1(from CodingGuidelines)
* running tests (from SubmittingPatches)Stuff I've seen you mention in emails over time:
*linux/scripts/checkpatch.pl
* git grep -e '\<inline\>' --and --not -e 'static inline' -- \*.h
* make -C t/ test-lint
test-lint is supposed to be run automatically as part of "make test" (or "make prove"), unless you've specifically disabled it by setting TEST_LINT. And it does complain for me with your patches. If it doesn't for you, then we have a bug to fix. :)
I won't be surprised, though, if you just ran "./t6036" manually before sending, since your patches literally didn't touch any other files.
In theory we could push some of the linting down into the test scripts themselves (some of it, like the &&-linter, is there already by necessity). But it might also end up annoying, since usually dropping down to manual single-test runs means you're trying to debug something, and extra linting processes could get in the way.
Quoted 1 line
Are there others?
I like:
make SANITIZE=address,undefined test
though it's pretty heavy-weight (but not nearly as much as valgrind). You probably also need BLK_SHA1=Yes, since the default DC_SHA1 has some unaligned loads that make UBSan complain. We should maybe teach the Makefile to do that by default.
I've also been playing with clang's scan-build. It _did_ find a real bug recently, but it has a bunch of false positives.
Stefan runs Coverity against pu periodically. IIRC It's a pain to run yourself, but the shared results can be mailed to you, or you can poke around at https://scan.coverity.com/projects/git. That _also_ has a ton of false positives, but it's good about cataloguing them so the periodic email usually just mentions the new ones.
-Peff
Quoted 15 lines · Jeff King
Quoted 4 lines · Elijah Newren
Oh, I didn't know about test-lint. Is there a place that documents the various checks you run, so I can avoid slowing you down? Ones I know about:
Quoted 8 lines
Already documented:
*make DEVELOPER=1(from CodingGuidelines)
* running tests (from SubmittingPatches)Stuff I've seen you mention in emails over time:
*linux/scripts/checkpatch.pl
* git grep -e '\<inline\>' --and --not -e 'static inline' -- \*.h
* make -C t/ test-lint
Quoted 4 lines
test-lint is supposed to be run automatically as part of "make test" (or "make prove"), unless you've specifically disabled it by setting
TEST_LINT. And it does complain for me with your patches. If it doesn't for you, then we have a bug to fix. :)
Oh, this may be my bad. Years ago someone pointed out that the testsuite could be run under 'prove', which provided nicer output and made sure to run the longest tests (e.g. the horrifically slow t9001-send-email.sh) first. So my test alias is:
time prove -j7 --timer --state failed,slow,save t[0-9]*.sh ::
"--root=/dev/shm"
(with possibly different -j settings on different machines) and I just stopped running make test. Didn't learn about the 'make prove' target, even though it's apparently now been there for nearly 8 years.
Quoted 2 lines
I won't be surprised, though, if you just ran "./t6036" manually before sending, since your patches literally didn't touch any other files.
That may also be true, though I would have missed it even if I had code changes due to not being aware of 'make prove'.
Quoted 17 lines
In theory we could push some of the linting down into the test scripts themselves (some of it, like the &&-linter, is there already by necessity). But it might also end up annoying, since usually dropping down to manual single-test runs means you're trying to debug something, and extra linting processes could get in the way.
Quoted 1 line
Are there others?
I like:
make SANITIZE=address,undefined test
though it's pretty heavy-weight (but not nearly as much as valgrind). You probably also need BLK_SHA1=Yes, since the default
DC_SHA1has some unaligned loads that make UBSan complain. We should maybe teach theMakefileto do that by default.
Quoted 8 lines
I've also been playing with clang's scan-build. It _did_ find a real bug recently, but it has a bunch of false positives.
Stefan runs Coverity against pu periodically. IIRC It's a pain to run yourself, but the shared results can be mailed to you, or you can poke around at https://scan.coverity.com/projects/git. That _also_ has a ton of false positives, but it's good about cataloguing them so the periodic email usually just mentions the new ones.
Cool, thanks for the pointers.
Quoted 5 lines · Elijah Newren
Quoted 4 lines
test-lint is supposed to be run automatically as part of "make test" (or "make prove"), unless you've specifically disabled it by setting
TEST_LINT. And it does complain for me with your patches. If it doesn't for you, then we have a bug to fix. :)
Quoted 7 lines
Oh, this may be my bad. Years ago someone pointed out that the testsuite could be run under 'prove', which provided nicer output and made sure to run the longest tests (e.g. the horrifically slow
t9001-send-email.sh) first. So my test alias is:time prove -j7 --timer --state failed,slow,save t[0-9]*.sh ::"--root=/dev/shm"
Heh, OK, that makes sense.
Quoted 3 lines
(with possibly different -j settings on different machines) and I just stopped running make test. Didn't learn about the 'make prove' target, even though it's apparently now been there for nearly 8 years.
I have:
GIT_TEST_OPTS = --root=/var/ram/git-tests GIT_PROVE_OPTS = -j16 --state=slow,save DEFAULT_TEST_TARGET = prove
in my config.mak. That lets me just do:
make test
from the top-level to get a build-and-test. It also allows just "make" from the "t" directory to do the right thing. Slightly annoyingly, "make test" in the "t" directory does the wrong thing, which bites me about once a month. ;)
-Peff
Quoted 16 lines · Elijah Newren
Quoted 15 lines · Junio C Hamano
Quoted 9 lines · Elijah Newren
When a merge succeeds, we expect the resulting contents to depend only upon the trees and blobs of the branches involved and of their merge base(s). Unfortunately, there are currently about half a dozen cases where the contents of a "successful" merge depend on the relative commit timestamps of the merge bases. Document these with testcases.
(This series came out of looking at modifying how file collision conflict types are handled, as discussed at [1]. I discovered these issues while working on that topic.)
I have a topic branch for this series but not merged to 'pu' as test-lint gives these:
...
Quoted 9 lines
... here's a fixup to the topic; as you pointed out, the exact contents of the script being written were actually irrelevant; it was just an input to a merge.
-- 8< --
Subject: [PATCH] fixup! t6036: add a failed conflict detection case: regular
files, different modes
Does a 'fixup!' commit require a Signed-off-by? Just realized that this one didn't have it, though I don't know if it's necessary. If it is:
Quoted 28 lines · Elijah Newren
Quoted 16 lines · Elijah Newren
Quoted 15 lines · Junio C Hamano
Quoted 9 lines · Elijah Newren
When a merge succeeds, we expect the resulting contents to depend only upon the trees and blobs of the branches involved and of their merge base(s). Unfortunately, there are currently about half a dozen cases where the contents of a "successful" merge depend on the relative commit timestamps of the merge bases. Document these with testcases.
(This series came out of looking at modifying how file collision conflict types are handled, as discussed at [1]. I discovered these issues while working on that topic.)
I have a topic branch for this series but not merged to 'pu' as test-lint gives these:
...
Quoted 9 lines
... here's a fixup to the topic; as you pointed out, the exact contents of the script being written were actually irrelevant; it was just an input to a merge.
-- 8< --
Subject: [PATCH] fixup! t6036: add a failed conflict detection case: regular
files, different modes
Quoted 5 lines
Does a 'fixup!' commit require a Signed-off-by? Just realized that this one didn't have it, though I don't know if it's necessary. If it is:
Signed-off-by Elijah Newren <[email protected]>
Thanks. I queued it separately before running out of time Monday, but will actually squash it in to the main patch.