7

We're setting up git 1.8 in a mixed environment (OSX, Linux, Windows) and there are filenames that use non-English characters. I've read that that core.precomposeunicode needs to be set to true on the OSX systems.

We're not concerned with backward compatibility. We are concerned with keeping things simple for the developers. We'd rather not have to explain about git configuration.

So: is it safe to set that flag globally (in the central git server)? Will that enforce the consistency we need? Is there a reason not to?

egrunin
  • 24,650
  • 8
  • 50
  • 93

2 Answers2

5

No, that won't work. There is no such thing as a central git server in a distributed version control system - at least not in the technical sense.

Each developer has his own repository to which he checks in his changes. When those changes are pushed to the repository you declare as central, the data is not re-processed.

You will have to set that configuration on every local repository.
Unfortunately, there is no alternative with .gitattributes either.

Local options for a certain repository that will then be cloned by the developers isn't an option either. The following simple experiment shows this:

d:\Temp\Origin>git init
Initialized empty Git repository in d:/Temp/Origin/.git/

d:\Temp\Origin>git config --local --add core.autocrlf input
d:\Temp\Origin>git config --local --list
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.autocrlf=input
d:\Temp\Origin>cd ..
d:\Temp>git clone d:\Temp\Origin Developer
Cloning into 'Developer'...
warning: You appear to have cloned an empty repository.
done.

d:\Temp>cd Developer

d:\Temp\Developer>git config --local --list
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.origin.url=d:\Temp\Origin
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

Note how the call to git config --local --list in Origin lists core.autocrlf=input and the same command in Developer doesn't, although we just cloned Developer from Origin.
That demonstrates that repository-local configuration values are not cloned.

Daniel Hilgarth
  • 171,043
  • 40
  • 335
  • 443
  • What I've been told is we want to "set the variable on the server so that it is inherited by the users" - are you saying this isn't how it works? (I can't find a clear explanation in the git docs, but probably I don't know what to ask for.) – egrunin Mar 05 '13 at 21:13
  • 2
    @egrunin: As I said: Technically, there simply *is no* central server. All repositories are technically on the same level. You can set a configuration option only for a specific repository. But that option will not be "transmitted" when you clone it. – Daniel Hilgarth Mar 05 '13 at 21:28
  • +1 This is very helpful. I'm going to show this to the team and make sure I've represented our question properly. – egrunin Mar 05 '13 at 23:36
  • We're still arguing over here, but I'm giving you the thumbs up anyway - thanks for the in-depth answer! – egrunin Mar 06 '13 at 16:48
  • 3
    @egrunin: You are welcome :) Working with git sometimes requires a bit of discipline from all involved. One idea though: You could create a script that creates the initial clone and sets the correct local configuration. – Daniel Hilgarth Mar 06 '13 at 16:51
1

While repository-local configuration values are not cloned, Git 2.37 (Q3 2022), will be more robust regarding core.precomposeunicode on Mac, for the fsmonitor (a daemon watching the working directory for file and directory changes using platform-specific file system notification facilities, communicating directly with commands like git status).

That way, setting core.precomposeunicode to true is better managed.

See commit 3294ca6, commit 53fcfbc, commit eb29901, commit 00991e1, commit 9915e08, commit d6d58ff, commit caa9c37, commit f954c7b, commit 7667f9d, commit b533708, commit 95a4e78, commit de7e0b5, commit 6504cfd, commit 90a70fa, commit d060555, commit 207534e, commit 802aa31, commit 39664e9, commit 8e8f4b8, commit 9968ed7, commit ddc5dac, commit d989b26, commit 1e7be10, commit a85ad67, commit 5c58fbd, commit d33c804, commit 62a62a2, commit 49b398a, commit 27b5d41, commit 40f865d (26 May 2022) by Jeff Hostetler (Jeff-Hostetler).
See commit 852e2c8 (25 Mar 2022) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit 9e496ff, 10 Jun 2022)

fsmonitor: on macOS also emit NFC spelling for NFD pathname

Signed-off-by: Jeff Hostetler

Emit NFC or NFC and NFD spellings of pathnames on macOS.

MacOS is Unicode composition insensitive, so NFC and NFD spellings are treated as aliases and collide.
While the spelling of pathnames in filesystem events depends upon the underlying filesystem, such as APFS, HFS+ or FAT32, the OS enforces such collisions regardless of filesystem.

Teach the daemon to always report the NFC spelling and to report the NFD spelling when stored in that format on the disk.

This is slightly more general than "core.precomposeUnicode".

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250