Torsten Bögershausen <tboegi@xxxxxx> 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?
