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

Junio C Hamano, Thu, May 22, 2008 11:04:09 +0200:

"Alex Riesen" [off-list ref] writes:

quoted

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

quoted

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

quoted

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.