Re: [PATCH] init: don't reset core.filemode on git-new-workdirs.

["Torsten Bögershausen" <tboegi@web.de>]

On Tue, Mar 23, 2021 at 10:45:38AM -0700, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> 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?

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) "$@"