[PATCH] Fix t6031 on filesystems without working exec bit

[PATCH] Fix t6031 on filesystems without working exec bit

[Alex Riesen]

The point of the test is not really to test the ability of the
filesystem to keep the given x-bit, but to check is merge-recursive
correctly handles it.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
 t/t6031-merge-recursive.sh |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/t/t6031-merge-recursive.sh b/t/t6031-merge-recursive.sh
index c8310ae..f1c91c8 100755
--- a/t/t6031-merge-recursive.sh
+++ b/t/t6031-merge-recursive.sh
@@ -12,8 +12,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 add file1 &&
+	git update-index --chmod=+x file1 &&
 	git commit -m b1 &&
 	git checkout a1 &&
 	git merge-recursive master -- a1 b1 &&
@@ -25,8 +24,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 add file2 &&
+	git update-index --add --chmod=+x file2 &&
 	git commit -m a2 &&
 	git checkout -b b2 master &&
 	: >file2 &&
-- 
1.5.5.1.354.g902c

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

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

> diff --git a/t/t6031-merge-recursive.sh b/t/t6031-merge-recursive.sh
> index c8310ae..f1c91c8 100755
> --- a/t/t6031-merge-recursive.sh
> +++ b/t/t6031-merge-recursive.sh
> @@ -12,8 +12,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 add file1 &&
> +	git update-index --chmod=+x file1 &&
>  	git commit -m b1 &&
>  	git checkout a1 &&
>  	git merge-recursive master -- a1 b1 &&

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

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?

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

[Alex Riesen]

Junio C Hamano, Mon, May 19, 2008 06:51:16 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > diff --git a/t/t6031-merge-recursive.sh b/t/t6031-merge-recursive.sh
> > index c8310ae..f1c91c8 100755
> > --- a/t/t6031-merge-recursive.sh
> > +++ b/t/t6031-merge-recursive.sh
> > @@ -12,8 +12,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 add file1 &&
> > +	git update-index --chmod=+x file1 &&
> >  	git commit -m b1 &&
> >  	git checkout a1 &&
> >  	git merge-recursive master -- a1 b1 &&
> 
> 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.

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

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

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

> Junio C Hamano, Mon, May 19, 2008 06:51:16 +0200:
> ...
>> 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...

>> 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 &&

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

[Alex Riesen]

2008/5/21 Junio C Hamano <gitster@pobox.com>:
> 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.

> -- >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 &&

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.

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

[Junio C Hamano]

"Alex Riesen" <raa.lkml@gmail.com> writes:

> 2008/5/21 Junio C Hamano <gitster@pobox.com>:
> ...
>> @@ -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 &&
>
> 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.

Doesn't it mean you spotted a bug?

If your repository is marked so that executable bit is untrustworthy
there, the check done when switching to branch "a1" to compare if "file1"
that is involved in the switch operation has local changes should ignore
(apparent and false) executable-bit change, shouldn't it?

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

[Alex Riesen]

Junio C Hamano, Thu, May 22, 2008 11:04:09 +0200:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
> 
> > 2008/5/21 Junio C Hamano <gitster@pobox.com>:
> > ...
> >> @@ -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 &&

Just retested this on my normal system, and of course you are right.
My patch breaks the t6031 there.

> > 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.
> 
> Doesn't it mean you spotted a bug?
> 

Looks like: builtin-merge-recursive.c does not seem to reference
trust_executable_bit (aka core.filemode) anywhere. The default
configuration statements are read in alright (there is a call to
git_default_config), it is just I am cannot find if the flag is used.

Johannes, in the meantime I lost the track of merge-recursive
completely. In this case, should I look at unpack-trees.c or is
it still somewhere inside merge-recursive (merge_file)?

> If your repository is marked so that executable bit is untrustworthy
> there, the check done when switching to branch "a1" to compare if "file1"
> that is involved in the switch operation has local changes should ignore
> (apparent and false) executable-bit change, shouldn't it?

Will see next monday, when I get back to that wretched laptop.

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

[Alex Riesen]

Alex Riesen, Thu, May 22, 2008 15:12:58 +0200:
> Junio C Hamano, Thu, May 22, 2008 11:04:09 +0200:
> > If your repository is marked so that executable bit is untrustworthy
> > there, the check done when switching to branch "a1" to compare if "file1"
> > that is involved in the switch operation has local changes should ignore
> > (apparent and false) executable-bit change, shouldn't it?
> 
> Will see next monday, when I get back to that wretched laptop.
> 

I managed to get my hands on it today and tried the test with your
modification. The test succeeds always and it succeeds with or without
the chmod. So it seems merge-recursive somehow ignores the x-bit from
working tree, I just cannot not find how and where.