Junio C Hamano, Thu, May 22, 2008 11:04:09 +0200: > "Alex Riesen" <raa.lkml@xxxxxxxxx> writes: > > > 2008/5/21 Junio C Hamano <gitster@xxxxxxxxx>: > > ... > >> @@ -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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
