Torsten Bögershausen [off-list ref] writes:
In the very long run, there may be room for improvements:
While core.filemode works for a loal repo on a local disk,
there are lots of cases where I whish a better handling.
But that is why we have multiple worktrees and per worktree
configuration, no?
Fundamentally, you cannot share a worktree from two systems and let
one work with filemode on while the other with filemode off, as you
summarized here:
Exporting a git repo from e.g.
Linux/ext4 to MacOs : Linux sees the execute-bit as is, MacOs has it always on
Linux/ext4 to Windows : Linux sees the execute-bit as is, MacOs has it always off
Visiting the same repo under Git-for-Windows and cygwin:
cygwin supports the executable bit, Git-for-Windows does not.
The "new-workdirs" was a cute hack that was quite useful before the
multiple worktree support materialized, and it and (proper) worktree
share the quirk that by default the per-repo configuration file is
shared.
And now we have the worktree (which may cross filesytem borders)
Today there are many use cases, where a single config variable is not ideal.
If there is a chance to have a "core.filemode=auto", which does probe the
filemode for this very OS/filesytem/worktree combination:
I would be happy to test/review/mentor such a code change.
I do not think we want to go there. filemode is not the only thing
that would be shared. What do you want to do with core.eol=native,
for example? Paths touched while switching branches get the 'native'
line endings on the system that the user happened to be on when the
"switch" command was run, and working tree files end up with mixture?
On Tue, Mar 23, 2021 at 10:45:38AM -0700, Junio C Hamano wrote:
Torsten Bögershausen [off-list ref] writes:
quoted
In the very long run, there may be room for improvements:
While core.filemode works for a loal repo on a local disk,
there are lots of cases where I whish a better handling.
But that is why we have multiple worktrees and per worktree
configuration, no?
Fundamentally, you cannot share a worktree from two systems and let
one work with filemode on while the other with filemode off, as you
summarized here:
quoted
Exporting a git repo from e.g.
Linux/ext4 to MacOs : Linux sees the execute-bit as is, MacOs has it always on
Linux/ext4 to Windows : Linux sees the execute-bit as is, MacOs has it always off
Visiting the same repo under Git-for-Windows and cygwin:
cygwin supports the executable bit, Git-for-Windows does not.
The "new-workdirs" was a cute hack that was quite useful before the
multiple worktree support materialized, and it and (proper) worktree
share the quirk that by default the per-repo configuration file is
shared.
quoted
And now we have the worktree (which may cross filesytem borders)
Today there are many use cases, where a single config variable is not ideal.
If there is a chance to have a "core.filemode=auto", which does probe the
filemode for this very OS/filesytem/worktree combination:
I would be happy to test/review/mentor such a code change.
I do not think we want to go there. filemode is not the only thing
that would be shared. What do you want to do with core.eol=native,
for example? Paths touched while switching branches get the 'native'
line endings on the system that the user happened to be on when the
"switch" command was run, and working tree files end up with mixture?
I don't intend to solve all possible confusions caused by sharing all
config variables - just this very one.
After some thinking, the following may illustrate a brute-force method,
not nice, neither optimized, nor perfect or bug free:
$ alias
alias git='~/bin2/git.sh'
cat ~/bin2/git.sh
#!/bin/sh
probe_executable()
{
touch $$.xxx
if test -x $$.xxx; then
rm $$.xxx
echo "-c core.filemode=false"
return
fi
chmod +x $$.xxx
if ! test -x $$.xxx; then
rm $$.xxx
echo "-c core.filemode=false"
return
fi
rm $$.xxx
return
}
git $(probe_executable) "$@"