Since #1618, which introduced `gix-merge::merge tree::run_baseline` and the functionality it tests, that test has failed on Windows when run with `GIX_TEST_IGNORE_ARCHIVES=1`. This happens because, while `chmod +x` commands run and exit indicating success in MSYS environments such as Git Bash, they do not actually make a change. Multiple cases (all sub-cases of the same faililing test) would fail this way. But the test fails fast, so only one is reported. The first to fail this way is `same-rename-different-mode`, which shows: --- STDERR: gix-merge::merge tree::run_baseline --- failed to extract 'tests\fixtures\generated-archives\tree-baseline.tar': Ignoring archive at 'tests\fixtures\generated-archives\tree-baseline.tar' as GIX_TEST_IGNORE_ARCHIVES is set. thread 'tree::run_baseline' panicked at gix-merge\tests\merge\tree\mod.rs:83:21: assertion `left != right` failed: same-rename-different-mode-A-B-reversed: Git caught up - adjust expectation Git works for the A/B case, but for B/A it forgets to set the executable bit left: Sha1(d75339daa64f3a1d98947623eee7bbb218e6c87d) right: Sha1(d75339daa64f3a1d98947623eee7bbb218e6c87d) This commit fixes that by using `git update-index --chmod=+x` to stage the intended effect of `chmod +x`. The `chmod +x` commands are still run, to avoid non-intended and potentially bug-prone or confusing differences between the metadata on disk and what is staged and commited, on systems where Unix-style permissions are supported on disk and `chmod +x` modifies them. Although only one of the two approaches is needed on any particular system in these tests, deciding based on the operating system is more complicated. It would also be misleading, because the effect of the two kinds of commands is not, in *general*, the same: one operates on files in the working tree, and the other operates on the index. Therefore, both are used, for simplicity and clarity. For readability, adjacent `chmod +x` commands are also combined into one. This way, each place that has both `chmod +x` logic and `git update-index --chmod=+x` logic can have a single command for each, that clearly relate to each other. As noted above, the change in this commit is not sufficient to fix that failing test, because a subsequent assertion still fails. This will be detailed and fixed in a subsequent commit. (This commit also does not yet update generated archives.)
Unified · Split
| @@ -475,8 +475,8 @@ git init same-rename-different-mode · 474 unmodified lines | |||
| 475 | 475 | ||
| 476 | git checkout A | 476 | git checkout A |
| 477 | write_lines 1 2 3 4 5 >a/x.f | 477 | write_lines 1 2 3 4 5 >a/x.f |
| 478 | chmod +x a/x.f | 478 | chmod +x a/x.f a/w |
| 479 | chmod +x a/w | 479 | git update-index --chmod=+x a/x.f a/w |
| 480 | git mv a a-renamed | 480 | git mv a a-renamed |
| 481 | git commit -am "changed all content, add +x, renamed a -> a-renamed" | 481 | git commit -am "changed all content, add +x, renamed a -> a-renamed" |
| 482 | 482 | ||
| @@ -486,8 +486,8 @@ git init same-rename-different-mode · 3 unmodified lines | |||
| 486 | git commit -am "changed all content, renamed a -> a-renamed" | 486 | git commit -am "changed all content, renamed a -> a-renamed" |
| 487 | 487 | ||
| 488 | git checkout expected | 488 | git checkout expected |
| 489 | chmod +x a/x.f | 489 | chmod +x a/x.f a/w |
| 490 | chmod +x a/w | 490 | git update-index --chmod=+x a/x.f a/w |
| 491 | write_lines 1 2 3 4 5 6 >a/x.f | 491 | write_lines 1 2 3 4 5 6 >a/x.f |
| 492 | git mv a a-renamed | 492 | git mv a a-renamed |
| 493 | git commit -am "Git, when branches are reversed, doesn't keep the +x flag on a/w so we specify our own expectation" | 493 | git commit -am "Git, when branches are reversed, doesn't keep the +x flag on a/w so we specify our own expectation" |