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

From: Alex Riesen <raa.lkml@gmail.com>
Date: May 22, 2008, 13:12 UTC
Message-ID: <20080522131258.GE3206@steel.home>
In-Reply-To: <7vskwawvzq.fsf@gitster.siamese.dyndns.org>

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

Show 10 quoted lines

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

Show 6 quoted lines

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