git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Torsten Bögershausen <tboegi@web.de>
Date
Mar 23, 2021, 20:31 UTC
Message-ID
<20210323203124.oxzqad2wmedelstu@tb-raspi4>
In-Reply-To
<xmqqo8f93gsd.fsf@gitster.g>
On Tue, Mar 23, 2021 at 10:45:38AM -0700, Junio C Hamano wrote:
Show 38 quoted lines
> 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) "$@"
Previous: Junio C HamanoNext: Junio C Hamano
Message 11 of 13 in “init: don't reset core.filemode on git-new-workdirs.”
  1. init: don't reset core.filemode on git-new-workdirs.Madhu, Mar 21, 2021
  2. Junio C HamanoMar 21, 2021
  3. MadhuMar 22, 2021
  4. Junio C HamanoMar 22, 2021
  5. MadhuMar 22, 2021
  6. Junio C HamanoMar 22, 2021
  7. MadhuMar 23, 2021
  8. Junio C HamanoMar 23, 2021
  9. Torsten BögershausenMar 23, 2021
  10. Junio C HamanoMar 23, 2021
  11. Torsten BögershausenMar 23, 2021
  12. Junio C HamanoMar 23, 2021
  13. MadhuJun 18, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.