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

inconsistent include behaviour for core.sharedRepository

From
GMGordon McGregor <gordon.mcgregor@nitero.com>
Date
Jan 30, 2014, 18:52 UTC
Message-ID
<CABJvL7duzsqH=3DLR6uhD05x2RmVJ=K53Up30K3sHOYzSfaLfw@mail.gmail.com>

After several days of problems with directory permissions in the objects/ directory for shared users, I finally found the cause of an issue that we have been seeing.

We are working with several shared repositories. We were trying to use a shared [include] configuration that contained

[core] sharedRepository = group

This was not being honoured, from an included config file.

Using git config, would show that core.sharedRepository was set to 'group', as expected.

However, digging through setup.c I see that shared_repository is actually configured using git_config_early(), which does not use the include mechanism that git_config()/ git_config_with_options() uses.

This is particularly difficult to debug given the git-config reports values that are not actually used internally.

I think that git config should report the correct values, for features that are accessed via git_config_early. Otherwise it is quite difficult to understand the behaviour, without the source code.

git version 1.8.2.1 on CentOS release 5.6 (Final)
-- 
Gordon McGregor
+1 512 577 9712
Message 1 of 1 in “inconsistent include behaviour for core.sharedRepository”
  1. Gordon McGregorJan 30, 2014

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.