Re: [PATCH] Fix t6031 on filesystems without working exec bit

Alex Riesen [off-list ref] writes:

Junio C Hamano, Mon, May 19, 2008 06:51:16 +0200:
...

quoted

I have to wonder if this is enough on a filesystem with usable executable
bit.  Has this been tested on both kinds of filesystems?

Yes and yes.

I am very much regretting for having extracted the above answer from you.
After actually running the test myself on a machine with executable bit, I
have to conclude that I now have to review any patch from you with much
more suspicion than I have done before.  Unless the test I ran on my
machine is lying to me, that is...

quoted

You aren't setting +x on work tree file anymore, but only flipping the bit
inside the index before committing.  Because of this change, after "b1"
commit, work tree has a local modification relative to the commit (namely,
reversion of chmod +x is in the work tree), which is different from the
original test sequence.  Doesn't this local modification interact with
switching to a1 branch and what merge-recursive does?

I think no (I depend on this in my workflows on both systems).

Look at what the "switch to a1 branch after committing to b1" does again.
You modify "file1" and commit to "b1" and you now have a local change in
file1 (because you update only the index and not the work tree) that is
effectively a revert of what you committed just now, and a1 and b1 differs
at that path.  You get "Entry 'file1' not uptodate. Cannot merge."  when
you try to switch to "a1".

    $ sh t6031-merge-recursive.sh -i -v
    * expecting success: 
            : >file1 &&
            git add file1 &&
            git commit -m initial &&
            git checkout -b a1 master &&
            : >dummy &&
            git add dummy &&
            git commit -m a &&
            git checkout -b b1 master &&
            git update-index --chmod=+x file1 &&
            git commit -m b1 &&
            git checkout a1 &&
            git merge-recursive master -- a1 b1 &&
            test -x file1

    Created initial commit bae7a40: initial
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 file1
    Switched to a new branch "a1"
    Created commit 1f64f65: a
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 dummy
    Switched to a new branch "b1"
    Created commit 98a1cf4: b1
     0 files changed, 0 insertions(+), 0 deletions(-)
     mode change 100644 => 100755 file1
    error: Entry 'file1' not uptodate. Cannot merge.
    * FAIL 1: mode change in one branch: keep changed version

If we squash the following on top of your patch, I think we can help
filesystems without executable bit without breaking filesystems with one.
Can you see if it works on your executable-bit-less setup?

-- >8 --
 t/t6031-merge-recursive.sh |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/t/t6031-merge-recursive.sh b/t/t6031-merge-recursive.sh
index f1c91c8..8073e0c 100755
--- a/t/t6031-merge-recursive.sh
+++ b/t/t6031-merge-recursive.sh

@@ -3,6 +3,9 @@
 test_description='merge-recursive: handle file mode'
 . ./test-lib.sh
 
+# Note that we follow "chmod +x F" with "update-index --chmod=+x F" to
+# help filesystems that do not have the executable bit.
+
 test_expect_success 'mode change in one branch: keep changed version' '
 	: >file1 &&
 	git add file1 &&

@@ -12,6 +15,7 @@ test_expect_success 'mode change in one branch: keep changed version' '
 	git add dummy &&
 	git commit -m a &&
 	git checkout -b b1 master &&
+	chmod +x file1 &&
 	git update-index --chmod=+x file1 &&
 	git commit -m b1 &&
 	git checkout a1 &&

@@ -24,6 +28,7 @@ test_expect_success 'mode change in both branches: expect conflict' '
 	git checkout -b a2 master &&
 	: >file2 &&
 	H=$(git hash-object file2) &&
+	chmod +x file2 &&
 	git update-index --add --chmod=+x file2 &&
 	git commit -m a2 &&
 	git checkout -b b2 master &&

2008/5/21 Junio C Hamano [off-list ref]:

Look at what the "switch to a1 branch after committing to b1" does again.
You modify "file1" and commit to "b1" and you now have a local change in
file1 (because you update only the index and not the work tree) that is
effectively a revert of what you committed just now, and a1 and b1 differs
at that path.  You get "Entry 'file1' not uptodate. Cannot merge."  when
you try to switch to "a1".

   $ sh t6031-merge-recursive.sh -i -v
   * expecting success:
           : >file1 &&
           git add file1 &&
           git commit -m initial &&
           git checkout -b a1 master &&
           : >dummy &&
           git add dummy &&
           git commit -m a &&
           git checkout -b b1 master &&
           git update-index --chmod=+x file1 &&
           git commit -m b1 &&
           git checkout a1 &&
           git merge-recursive master -- a1 b1 &&
           test -x file1

   Created initial commit bae7a40: initial
    0 files changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 file1
   Switched to a new branch "a1"
   Created commit 1f64f65: a
    0 files changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 dummy
   Switched to a new branch "b1"
   Created commit 98a1cf4: b1
    0 files changed, 0 insertions(+), 0 deletions(-)
    mode change 100644 => 100755 file1
   error: Entry 'file1' not uptodate. Cannot merge.
   * FAIL 1: mode change in one branch: keep changed version

It did work for me when I tried it back then. Maybe I just accidentally
tested something else.

If we squash the following on top of your patch, I think we can help
filesystems without executable bit without breaking filesystems with one.
Can you see if it works on your executable-bit-less setup?

Not in the moment.

Now, this is pointless in my setup. Cygwin just ignores the operation
and decidedddds (presumably according the file _content_ or maybe
phase of the moon) that is not executable. Working tree is still modified.

Maybe I should just live with it (and disable the test locally). It is just
very broken system which hopefully no one besides me ever gets to see.