From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Madhu <enometh@meer.net>, git@vger.kernel.org
Subject: Re: [PATCH] init: don't reset core.filemode on git-new-workdirs.
Date: Tue, 23 Mar 2021 10:45:38 -0700 [thread overview]
Message-ID: <xmqqo8f93gsd.fsf@gitster.g> (raw)
In-Reply-To: <20210323165335.urvvccwnhahxmokt@tb-raspi4> ("Torsten Bögershausen"'s message of "Tue, 23 Mar 2021 17:53:35 +0100")
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?
next prev parent reply other threads:[~2021-03-23 17:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-21 12:28 [PATCH] init: don't reset core.filemode on git-new-workdirs Madhu
2021-03-21 21:58 ` Junio C Hamano
2021-03-22 2:40 ` Madhu
2021-03-22 4:53 ` Junio C Hamano
2021-03-22 9:04 ` Madhu
2021-03-22 18:02 ` Junio C Hamano
2021-03-23 3:57 ` Madhu
2021-03-23 6:39 ` Junio C Hamano
2021-03-23 16:53 ` Torsten Bögershausen
2021-03-23 17:45 ` Junio C Hamano [this message]
2021-03-23 20:31 ` Torsten Bögershausen
2021-03-23 20:50 ` Junio C Hamano
2021-06-18 4:18 ` Madhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqo8f93gsd.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=enometh@meer.net \
--cc=git@vger.kernel.org \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).