path: root/setup.c
AgeCommit message (Collapse)Author
2021-09-10setup: use xopen and xdup in sanitize_stdfdsRené Scharfe
Replace the catch-all error message with specific ones for opening and duplicating by calling the wrappers xopen and xdup. The code becomes easier to follow when error handling is reduced to two letters. Remove the unnecessary mode parameter while at it -- we expect /dev/null to already exist. Signed-off-by: René Scharfe <> Signed-off-by: Junio C Hamano <>
2021-07-17Merge branch 'jt/partial-clone-submodule-1'Junio C Hamano
Prepare the internals for lazily fetching objects in submodules from their promisor remotes. * jt/partial-clone-submodule-1: promisor-remote: teach lazy-fetch in any repo run-command: refactor subprocess env preparation submodule: refrain from filtering GIT_CONFIG_COUNT promisor-remote: support per-repository config repository: move global r_f_p_c to repo struct
2021-06-28repository: move global r_f_p_c to repo structJonathan Tan
Move repository_format_partial_clone, which is currently a global variable, into struct repository. (Full support for per-repository partial clone config will be done in a subsequent commit - this is split into its own commit because of the extent of the changes needed.) The new repo-specific variable cannot be set in check_repository_format_gently() (as is currently), because that function does not know which repo it is operating on (or even whether the value is important); therefore this responsibility is delegated to the outermost caller that knows. Of all the outermost callers that know (found by looking at all functions that call clear_repository_format()), I looked at those that either read from the main Git directory or write into a struct repository. These callers have been modified accordingly (write to the_repository in the former case and write to the given struct repository in the latter case). Signed-off-by: Jonathan Tan <> Signed-off-by: Junio C Hamano <> Reviewed-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2021-05-20setup: split "extensions found" messages into singular and pluralAlex Henrie
It's easier to translate this way. Signed-off-by: Alex Henrie <> Signed-off-by: Junio C Hamano <>
2021-04-06macOS: precompose startup_info->prefixTorsten Bögershausen
The "prefix" was precomposed for macOS in commit 5c327502 (MacOS: precompose_argv_prefix(), 2021-02-03). However, this commit forgot to update "startup_info->prefix" after precomposing. Move the (possible) precomposition towards the end of setup_git_directory_gently(), so that precompose_string_if_needed() can use git_config_get_bool("core.precomposeunicode") correctly. Keep prefix, startup_info->prefix and GIT_PREFIX_ENVIRONMENT all in sync. And as a result, the prefix no longer needs to be precomposed in git.c Reported-by: Dmitry Torilov <> Helped-by: Junio C Hamano <> Signed-off-by: Torsten Bögershausen <> Signed-off-by: Junio C Hamano <>
2020-08-12Merge branch 'bc/sha-256-part-3'Junio C Hamano
The final leg of SHA-256 transition. * bc/sha-256-part-3: (39 commits) t: remove test_oid_init in tests docs: add documentation for extensions.objectFormat ci: run tests with SHA-256 t: make SHA1 prerequisite depend on default hash t: allow testing different hash algorithms via environment t: add test_oid option to select hash algorithm repository: enable SHA-256 support by default setup: add support for reading extensions.objectformat bundle: add new version for use with SHA-256 builtin/verify-pack: implement an --object-format option http-fetch: set up git directory before parsing pack hashes t0410: mark test with SHA1 prerequisite t5308: make test work with SHA-256 t9700: make hash size independent t9500: ensure that algorithm info is preserved in config t9350: make hash size independent t9301: make hash size independent t9300: use $ZERO_OID instead of hard-coded object ID t9300: abstract away SHA-1-specific constants t8011: make hash size independent ...
2020-07-30Merge branch 'jk/reject-newer-extensions-in-v0' into masterJunio C Hamano
With the base fix to 2.27 regresion, any new extensions in a v0 repository would still be silently honored, which is not quite right. Instead, complain and die loudly. * jk/reject-newer-extensions-in-v0: verify_repository_format(): complain about new extensions in v0 repo
2020-07-30setup: add support for reading extensions.objectformatbrian m. carlson
The transition plan specifies extensions.objectFormat as the indication that we're using a given hash in a certain repo. Read this as one of the extensions we support. If the user has specified an invalid value, fail. Ensure that we reject the extension if the repository format version is 0. Signed-off-by: brian m. carlson <> Reviewed-by: Eric Sunshine <> Signed-off-by: Junio C Hamano <>
2020-07-17Merge branch 'jn/v0-with-extensions-fix' into masterJunio C Hamano
In 2.28-rc0, we corrected a bug that some repository extensions are honored by mistake even in a version 0 repositories (these configuration variables in extensions.* namespace were supposed to have special meaning in repositories whose version numbers are 1 or higher), but this was a bit too big a change. * jn/v0-with-extensions-fix: repository: allow repository format upgrade with extensions Revert "check_repository_format_gently(): refuse extensions for old repositories"
2020-07-16verify_repository_format(): complain about new extensions in v0 repoJeff King
We made the mistake in the past of respecting extensions.* even when the repository format version was set to 0. This is bad because forgetting to bump the repository version means that older versions of Git (which do not know about our extensions) won't complain. I.e., it's not a problem in itself, but it means your repository is in a state which does not give you the protection you think you're getting from older versions. For compatibility reasons, we are stuck with that decision for existing extensions. However, we'd prefer not to extend the damage further. We can do that by catching any newly-added extensions and complaining about the repository format. Note that this is a pretty heavy hammer: we'll refuse to work with the repository at all. A lesser option would be to ignore (possibly with a warning) any new extensions. But because of the way the extensions are handled, that puts the burden on each new extension that is added to remember to "undo" itself (because they are handled before we know for sure whether we are in a v1 repo or not, since we don't insist on a particular ordering of config entries). So one option would be to rewrite that handling to record any new extensions (and their values) during the config parse, and then only after proceed to handle new ones only if we're in a v1 repository. But I'm not sure if it's worth the trouble: - ignoring extensions is likely to end up with broken results anyway (e.g., ignoring a proposed objectformat extension means parsing any object data is likely to encounter errors) - this is a sign that whatever tool wrote the extension field is broken. We may be better off notifying immediately and forcefully so that such tools don't even appear to work accidentally. The only downside is that fixing the situation is a little tricky, because programs like "git config" won't want to work with the repository. But: git config --file=.git/config core.repositoryformatversion 1 should still suffice. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2020-07-16repository: allow repository format upgrade with extensionsJonathan Nieder
Now that we officially permit repository extensions in repository format v0, permit upgrading a repository with extensions from v0 to v1 as well. For example, this means a repository where the user has set "extensions.preciousObjects" can use "git fetch --filter=blob:none origin" to upgrade the repository to use v1 and the partial clone extension. To avoid mistakes, continue to forbid repository format upgrades in v0 repositories with an unrecognized extension. This way, a v0 user using a misspelled extension field gets a chance to correct the mistake before updating to the less forgiving v1 format. While we're here, make the error message for failure to upgrade the repository format a bit shorter, and present it as an error, not a warning. Reported-by: Huan Huan Chen <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2020-07-16Revert "check_repository_format_gently(): refuse extensions for old ↵Jonathan Nieder
repositories" This reverts commit 14c7fa269e42df4133edd9ae7763b678ed6594cd. The core.repositoryFormatVersion field was introduced in ab9cb76f661 (Repository format version check., 2005-11-25), providing a welcome bit of forward compatibility, thanks to some welcome analysis by Martin Atukunda. The semantics are simple: a repository with core.repositoryFormatVersion set to 0 should be comprehensible by all Git implementations in active use; and Git implementations should error out early instead of trying to act on Git repositories with higher core.repositoryFormatVersion values representing new formats that they do not understand. A new repository format did not need to be defined until 00a09d57eb8 (introduce "extensions" form of core.repositoryformatversion, 2015-06-23). This provided a finer-grained extension mechanism for Git repositories. In a repository with core.repositoryFormatVersion set to 1, Git implementations can act on "extensions.*" settings that modify how a repository is interpreted. In repository format version 1, unrecognized extensions settings cause Git to error out. What happens if a user sets an extension setting but forgets to increase the repository format version to 1? The extension settings were still recognized in that case; worse, unrecognized extensions settings do *not* cause Git to error out. So combining repository format version 0 with extensions settings produces in some sense the worst of both worlds. To improve that situation, since 14c7fa269e4 (check_repository_format_gently(): refuse extensions for old repositories, 2020-06-05) Git instead ignores extensions in v0 mode. This way, v0 repositories get the historical (pre-2015) behavior and maintain compatibility with Git implementations that do not know about the v1 format. Unfortunately, users had been using this sort of configuration and this behavior change came to many as a surprise: - users of "git config --worktree" that had followed its advice to enable extensions.worktreeConfig (without also increasing the repository format version) would find their worktree configuration no longer taking effect - tools such as copybara[*] that had set extensions.partialClone in existing repositories (without also increasing the repository format version) would find that setting no longer taking effect The behavior introduced in 14c7fa269e4 might be a good behavior if we were traveling back in time to 2015, but we're far too late. For some reason I thought that it was what had been originally implemented and that it had regressed. Apologies for not doing my research when 14c7fa269e4 was under development. Let's return to the behavior we've had since 2015: always act on extensions.* settings, regardless of repository format version. While we're here, include some tests to describe the effect on the "upgrade repository version" code path. [*] Reported-by: Johannes Schindelin <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2020-07-07Merge branch 'bc/sha-256-part-2'Junio C Hamano
SHA-256 migration work continues. * bc/sha-256-part-2: (44 commits) remote-testgit: adapt for object-format bundle: detect hash algorithm when reading refs t5300: pass --object-format to git index-pack t5704: send object-format capability with SHA-256 t5703: use object-format serve option t5702: offer an object-format capability in the test t/helper: initialize the repository for test-sha1-array remote-curl: avoid truncating refs with ls-remote t1050: pass algorithm to index-pack when outside repo builtin/index-pack: add option to specify hash algorithm remote-curl: detect algorithm for dumb HTTP by size builtin/ls-remote: initialize repository based on fetch t5500: make hash independent serve: advertise object-format capability for protocol v2 connect: parse v2 refs with correct hash algorithm connect: pass full packet reader when parsing v2 refs Documentation/technical: document object-format for protocol v2 t1302: expect repo format version 1 for SHA-256 builtin/show-index: provide options to determine hash algo t5302: modernize test formatting ...
2020-06-05check_repository_format_gently(): refuse extensions for old repositoriesXin Li
Previously, extensions were recognized regardless of repository format version.  If the user sets an undefined "extensions" value on a repository of version 0 and that value is used by a future git version, they might get an undesired result. Because all extensions now also upgrade repository versions, tightening the check would help avoid this for future extensions. Signed-off-by: Xin Li <> Signed-off-by: Junio C Hamano <>
2020-06-05repository: add a helper function to perform repository format upgradeXin Li
In version 1 of repository format, "extensions" gained special meaning and it is safer to avoid upgrading when there are pre-existing extensions. Make list-objects-filter to use the helper function instead of setting repository version directly as a prerequisite of exposing the upgrade capability. Signed-off-by: Xin Li <> Signed-off-by: Junio C Hamano <>
2020-05-27setup: set the_repository's hash algo when checking formatbrian m. carlson
When we're checking the repository's format, set the hash algorithm at the same time. This ensures that we perform a suitable initialization early enough to avoid confusing any parts of the code. If we defer until later, we can end up with portions of the code which are confused about the hash algorithm, resulting in segfaults when working with SHA-256 repositories. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2020-03-27Merge branch 'bc/sha-256-part-1-of-4'Junio C Hamano
SHA-256 transition continues. * bc/sha-256-part-1-of-4: (22 commits) fast-import: add options for rewriting submodules fast-import: add a generic function to iterate over marks fast-import: make find_marks work on any mark set fast-import: add helper function for inserting mark object entries fast-import: permit reading multiple marks files commit: use expected signature header for SHA-256 worktree: allow repository version 1 init-db: move writing repo version into a function builtin/init-db: add environment variable for new repo hash builtin/init-db: allow specifying hash algorithm on command line setup: allow check_repository_format to read repository format t/helper: make repository tests hash independent t/helper: initialize repository if necessary t/helper/test-dump-split-index: initialize git repository t6300: make hash algorithm independent t6300: abstract away SHA-1-specific constants t: use hash-specific lookup tables to define test constants repository: require a build flag to use SHA-256 hex: add functions to parse hex object IDs in any algorithm hex: introduce parsing variants taking hash algorithms ...
2020-03-25Merge branch 'am/real-path-fix'Junio C Hamano
The real_path() convenience function can easily be misused; with a bit of code refactoring in the callers' side, its use has been eliminated. * am/real-path-fix: get_superproject_working_tree(): return strbuf real_path_if_valid(): remove unsafe API real_path: remove unsafe API set_git_dir: fix crash when used with real_path()
2020-03-16Merge branch 'es/outside-repo-errmsg-hints'Junio C Hamano
An earlier update to show the location of working tree in the error message did not consider the possibility that a git command may be run in a bare repository, which has been corrected. * es/outside-repo-errmsg-hints: prefix_path: show gitdir if worktree unavailable
2020-03-15prefix_path: show gitdir if worktree unavailableEmily Shaffer
If there is no worktree at present, we can still hint the user about Git's current directory by showing them the absolute path to the Git directory. Even though the Git directory doesn't make it as easy to locate the worktree in question, it can still help a user figure out what's going on while developing a script. This fixes a segmentation fault introduced in e0020b2f ("prefix_path: show gitdir when arg is outside repo", 2020-02-14). Signed-off-by: Emily Shaffer <> [jc: added minimum tests, with help from Szeder Gábor] Signed-off-by: Junio C Hamano <>
2020-03-10real_path_if_valid(): remove unsafe APIAlexandr Miloslavskiy
This commit continues the work started with previous commit. Signed-off-by: Alexandr Miloslavskiy <> Signed-off-by: Junio C Hamano <>
2020-03-10real_path: remove unsafe APIAlexandr Miloslavskiy
Returning a shared buffer invites very subtle bugs due to reentrancy or multi-threading, as demonstrated by the previous patch. There was an unfinished effort to abolish this [1]. Let's finally rid of `real_path()`, using `strbuf_realpath()` instead. This patch uses a local `strbuf` for most places where `real_path()` was previously called. However, two places return the value of `real_path()` to the caller. For them, a `static` local `strbuf` was added, effectively pushing the problem one level higher: read_gitfile_gently() get_superproject_working_tree() [1] Signed-off-by: Alexandr Miloslavskiy <> Signed-off-by: Junio C Hamano <>
2020-03-06set_git_dir: fix crash when used with real_path()Alexandr Miloslavskiy
`real_path()` returns result from a shared buffer, inviting subtle reentrance bugs. One of these bugs occur when invoked this way: set_git_dir(real_path(git_dir)) In this case, `real_path()` has reentrance: real_path read_gitfile_gently repo_set_gitdir setup_git_env set_git_dir_1 set_git_dir Later, `set_git_dir()` uses its now-dead parameter: !is_absolute_path(path) Fix this by using a dedicated `strbuf` to hold `strbuf_realpath()`. Signed-off-by: Alexandr Miloslavskiy <> Signed-off-by: Junio C Hamano <>
2020-02-24setup: allow check_repository_format to read repository formatbrian m. carlson
In some cases, we will want to not only check the repository format, but extract the information that we've gained. To do so, allow check_repository_format to take a pointer to struct repository_format. Allow passing NULL for this argument if we're not interested in the information, and pass NULL for all existing callers. A future patch will make use of this information. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2020-02-17Merge branch 'es/outside-repo-errmsg-hints'Junio C Hamano
Error message clarification. * es/outside-repo-errmsg-hints: prefix_path: show gitdir when arg is outside repo
2020-02-16prefix_path: show gitdir when arg is outside repoEmily Shaffer
When developing a script, it can be painful to understand why Git thinks something is outside the current repo, if the current repo isn't what the user thinks it is. Since this can be tricky to diagnose, especially in cases like submodules or nested worktrees, let's give the user a hint about which repository is offended about that path. Signed-off-by: Emily Shaffer <> Acked-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2020-01-27verify_filename(): handle backslashes in "wildcards are pathspecs" ruleJeff King
Commit 28fcc0b71a (pathspec: avoid the need of "--" when wildcard is used, 2015-05-02) allowed: git rev-parse '*.c' without the double-dash. But the rule it uses to check for wildcards actually looks for any glob special. This is overly liberal, as it means that a pattern that doesn't actually do any wildcard matching, like "a\b", will be considered a pathspec. If you do have such a file on disk, that's presumably what you wanted. But if you don't, the results are confusing: rather than say "there's no such path a\b", we'll quietly accept it as a pathspec which very likely matches nothing (or at least not what you intended). Likewise, looking for path "a\*b" doesn't expand the search at all; it would only find a single entry, "a*b". This commit switches the rule to trigger only when glob metacharacters would expand the search, meaning both of those cases will now report an error (you can still disambiguate using "--", of course; we're just tightening the DWIM heuristic). Note that we didn't test the original feature in 28fcc0b71a at all. So this patch not only tests for these corner cases, but also adds a regression test for the existing behavior. Reported-by: David Burström <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2019-09-30Merge branch 'js/gitdir-at-unc-root'Junio C Hamano
On Windows, the root level of UNC share is now allowed to be used just like any other directory. * js/gitdir-at-unc-root: setup_git_directory(): handle UNC root paths correctly Fix .git/ discovery at the root of UNC shares setup_git_directory(): handle UNC paths correctly
2019-08-26setup_git_directory(): handle UNC root paths correctlyJohannes Schindelin
When working in the root directory of a file share (this is only possible in Git Bash and Powershell, but not in CMD), the current directory is reported without a trailing slash. This is different from Unix and standard Windows directories: both / and C:\ are reported with a trailing slash as current directories. If a Git worktree is located there, Git is not quite prepared for that: while it does manage to find the .git directory/file, it returns as length of the top-level directory's path *one more* than the length of the current directory, and setup_git_directory_gently() would then return an undefined string as prefix. In practice, this undefined string usually points to NUL bytes, and does not cause much harm. Under rare circumstances that are really involved to reproduce (and not reliably so), the reported prefix could be a suffix string of Git's exec path, though. A careful analysis determined that this bug is unlikely to be exploitable, therefore we mark this as a regular bug fix. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-08-26Fix .git/ discovery at the root of UNC sharesJohannes Schindelin
A very common assumption in Git's source code base is that offset_1st_component() returns either 0 for relative paths, or 1 for absolute paths that start with a slash. In other words, the return value is either 0 or points just after the dir separator. This assumption is not fulfilled when calling offset_1st_component() e.g. on UNC paths on Windows, e.g. "//my-server/my-share". In this case, offset_1st_component() returns the length of the entire string (which is correct, because stripping the last "component" would not result in a valid directory), yet the return value still does not point just after a dir separator. This assumption is most prominently seen in the setup_git_directory_gently_1() function, where we want to append a ".git" component and simply assume that there is already a dir separator. In the UNC example given above, this assumption is incorrect. As a consequence, Git will fail to handle a worktree at the top of a UNC share correctly. Let's fix this by adding a dir separator specifically for that case: we found that there is no first component in the path and it does not end in a dir separator? Then add it. This fixes Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-08-26setup_git_directory(): handle UNC paths correctlyJohannes Schindelin
The first offset in a UNC path is not the host name, but the folder name after that. This fixes Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-06-25Move repository_format_partial_clone to promisor-remote.cChristian Couder
Now that we have has_promisor_remote() and can use many promisor remotes, let's hide repository_format_partial_clone as a static in promisor-remote.c to avoid it being use for anything other than managing backward compatibility. Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2019-04-16sha1-name.c: remove the_repo from maybe_die_on_misspelt_object_nameNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-03-20Merge branch 'ma/clear-repository-format'Junio C Hamano
The setup code has been cleaned up to avoid leaks around the repository_format structure. * ma/clear-repository-format: setup: fix memory leaks with `struct repository_format` setup: free old value before setting `work_tree`
2019-02-28setup: fix memory leaks with `struct repository_format`Martin Ågren
After we set up a `struct repository_format`, it owns various pieces of allocated memory. We then either use those members, because we decide we want to use the "candidate" repository format, or we discard the candidate / scratch space. In the first case, we transfer ownership of the memory to a few global variables. In the latter case, we just silently drop the struct and end up leaking memory. Introduce an initialization macro `REPOSITORY_FORMAT_INIT` and a function `clear_repository_format()`, to be used on each side of `read_repository_format()`. To have a clear and simple memory ownership, let all users of `struct repository_format` duplicate the strings that they take from it, rather than stealing the pointers. Call `clear_...()` at the start of `read_...()` instead of just zeroing the struct, since we sometimes enter the function multiple times. Thus, it is important to initialize the struct before calling `read_...()`, so document that. It's also important because we might not even call `read_...()` before we call `clear_...()`, see, e.g., builtin/init-db.c. Teach `read_...()` to clear the struct on error, so that it is reset to a safe state, and document this. (In `setup_git_directory_gently()`, we look at `repo_fmt.hash_algo` even if `repo_fmt.version` is -1, which we weren't actually supposed to do per the API. After this commit, that's ok.) We inherit the existing code's combining "error" and "no version found". Both are signalled through `version == -1` and now both cause us to clear any partial configuration we have picked up. For "extensions.*", that's fine, since they require a positive version number. For "core.bare" and "core.worktree", we're already verifying that we have a non-negative version number before using them. Signed-off-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2019-02-05Merge branch 'js/abspath-part-inside-repo'Junio C Hamano
On a case-insensitive filesystem, we failed to compare the part of the path that is above the worktree directory in an absolute pathname, which has been corrected. * js/abspath-part-inside-repo: abspath_part_inside_repo: respect core.ignoreCase
2019-01-23setup: free old value before setting `work_tree`Martin Ågren
Before assigning to `data->work_tree` in `read_worktree_config()`, free any value we might already have picked up, so that we do not leak it. Signed-off-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2019-01-18abspath_part_inside_repo: respect core.ignoreCaseJohannes Schindelin
If the file system is case-insensitive, we really must be careful to ignore differences in case only. This fixes Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-01-03Simplify handling of setup_git_directory_gently() failure cases.Erin Dahlgren
setup_git_directory_gently() expects two types of failures to discover a git directory (e.g. .git/): - GIT_DIR_HIT_CEILING: could not find a git directory in any parent directories of the cwd. - GIT_DIR_HIT_MOUNT_POINT: could not find a git directory in any parent directories up to the mount point of the cwd. Both cases are handled in a similar way, but there are misleading and unimportant differences. In both cases, setup_git_directory_gently() should: - Die if we are not in a git repository. Otherwise: - Set nongit_ok = 1, indicating that we are not in a git repository but this is ok. - Call strbuf_release() on any non-static struct strbufs that we allocated. Before this change are two misleading additional behaviors: - GIT_DIR_HIT_CEILING: setup_nongit() changes to the cwd for no apparent reason. We never had the chance to change directories up to this point so chdir(current cwd) is pointless. - GIT_DIR_HIT_MOUNT_POINT: strbuf_release() frees the buffer of a static struct strbuf (cwd). This is unnecessary because the struct is static so its buffer is always reachable. This is also misleading because nowhere else in the function is this buffer released. This change eliminates these two misleading additional behaviors and deletes setup_nogit() because the code is clearer without it. The result is that we can see clearly that GIT_DIR_HIT_CEILING and GIT_DIR_HIT_MOUNT_POINT lead to the same behavior (ignoring the different help messages). During review, this change was amended to additionally include: - Neither GIT_DIR_HIT_CEILING nor GIT_DIR_HIT_MOUNT_POINT may return early from setup_git_directory_gently() before the GIT_PREFIX environment variable is reset. Change both cases to break instead of return. See GIT_PREFIX below for more details. - GIT_DIR_NONE: setup_git_directory_gently_1() never returns this value, but if it ever did, setup_git_directory_gently() would incorrectly record that it had found a repository. Explicitly BUG on this case because it is underspecified. - GIT_PREFIX: this environment variable must always match the value of startup_info->prefix and the prefix returned from setup_git_directory_gently(). Make how we handle this slightly more repetitive but also more clear. - setup_git_env() and repo_set_hash_algo(): Add comments showing that only GIT_DIR_EXPLICIT, GIT_DIR_DISCOVERED, and GIT_DIR_BARE will cause setup_git_directory_gently() to call these setup functions. This was obvious (but partly incorrect) before this change when GIT_DIR_HIT_MOUNT_POINT returned early from setup_git_directory_gently(). Signed-off-by: Junio C Hamano <>
2018-10-22worktree: add per-worktree config filesNguyễn Thái Ngọc Duy
A new repo extension is added, worktreeConfig. When it is present: - Repository config reading by default includes $GIT_DIR/config _and_ $GIT_DIR/config.worktree. "config" file remains shared in multiple worktree setup. - The special treatment for core.bare and core.worktree, to stay effective only in main worktree, is gone. These config settings are supposed to be in config.worktree. This extension is most useful in multiple worktree setup because you now have an option to store per-worktree config (which is either .git/config.worktree for main worktree, or .git/worktrees/xx/config.worktree for linked ones). This extension can be used in single worktree mode, even though it's pretty much useless (but this can happen after you remove all linked worktrees and move back to single worktree). "git config" reads from both "config" and "config.worktree" by default (i.e. without either --user, --file...) when this extension is present. Default writes still go to "config", not "config.worktree". A new option --worktree is added for that (*). Since a new repo extension is introduced, existing git binaries should refuse to access to the repo (both from main and linked worktrees). So they will not misread the config file (i.e. skip the config.worktree part). They may still accidentally write to the config file anyway if they use with "git config --file <path>". This design places a bet on the assumption that the majority of config variables are shared so it is the default mode. A safer move would be default writes go to per-worktree file, so that accidental changes are isolated. (*) "git config --worktree" points back to "config" file when this extension is not present and there is only one worktree so that it works in any both single and multiple worktree setups. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-06Replace all die("BUG: ...") calls by BUG() onesJohannes Schindelin
In d8193743e08 (usage.c: add BUG() function, 2017-05-12), a new macro was introduced to use for reporting bugs instead of die(). It was then subsequently used to convert one single caller in 588a538ae55 (setup_git_env: convert die("BUG") to BUG(), 2017-05-12). The cover letter of the patch series containing this patch (cf is not terribly clear why only one call site was converted, or what the plan is for other, similar calls to die() to report bugs. Let's just convert all remaining ones in one fell swoop. This trick was performed by this invocation: sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c) Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-04-25Merge branch 'jk/relative-directory-fix'Junio C Hamano
Some codepaths, including the refs API, get and keep relative paths, that go out of sync when the process does chdir(2). The chdir-notify API is introduced to let these codepaths adjust these cached paths to the new current directory. * jk/relative-directory-fix: refs: use chdir_notify to update cached relative paths set_work_tree: use chdir_notify add chdir-notify API trace.c: export trace_setup_key set_git_dir: die when setenv() fails
2018-04-10Merge branch 'nd/remove-ignore-env-field'Junio C Hamano
Code clean-up for the "repository" abstraction. * nd/remove-ignore-env-field: repository.h: add comment and clarify repo_set_gitdir repository: delete ignore_env member sha1_file.c: move delayed getenv(altdb) back to setup_git_env() repository.c: delete dead functions repository.c: move env-related setup code back to environment.c repository: initialize the_repository in main()
2018-03-30set_work_tree: use chdir_notifyJeff King
When we change to the top of the working tree, we manually re-adjust $GIT_DIR and call set_git_dir() again, in order to update any relative git-dir we'd compute earlier. Instead of the work-tree code having to know to call the git-dir code, let's use the new chdir_notify interface. There are two spots that need updating, with a few subtleties in each: 1. the set_git_dir() code needs to chdir_notify_register() so it can be told when to update its path. Technically we could push this down into repo_set_gitdir(), so that even repository structs besides the_repository could benefit from this. But that opens up a lot of complications: - we'd still need to touch set_git_dir(), because it does some other setup (like setting $GIT_DIR in the environment) - submodules using other repository structs get cleaned up, which means we'd need to remove them from the chdir_notify list - it's unlikely to fix any bugs, since we shouldn't generally chdir() in the middle of working on a submodule 2. setup_work_tree now needs to call chdir_notify(), and can lose its manual set_git_dir() call. Note that at first glance it looks like this undoes the absolute-to-relative optimization added by 044bbbcb63 (Make git_dir a path relative to work_tree in setup_work_tree(), 2008-06-19). But for the most part that optimization was just _undoing_ the relative-to-absolute conversion which the function was doing earlier (and which is now gone). It is true that if you already have an absolute git_dir that the setup_work_tree() function will no longer make it relative as a side effect. But: - we generally do have relative git-dir's due to the way the discovery code works - if we really care about making git-dir's relative when possible, then we should be relativizing them earlier (e.g., when we see an absolute $GIT_DIR we could turn it relative, whether we are going to chdir into a worktree or not). That would cover all cases, including ones that 044bbbcb63 did not. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2018-03-05repository.c: move env-related setup code back to environment.cNguyễn Thái Ngọc Duy
It does not make sense that generic repository code contains handling of environment variables, which are specific for the main repository only. Refactor repo_set_gitdir() function to take $GIT_DIR and optionally _all_ other customizable paths. These optional paths can be NULL and will be calculated according to the default directory layout. Note that some dead functions are left behind to reduce diff noise. They will be deleted in the next patch. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-02-27Merge branch 'as/ll-i18n'Junio C Hamano
Some messages in low level start-up codepath have been i18n-ized. * as/ll-i18n: Mark messages for translations
2018-02-13Merge branch 'jh/fsck-promisors'Junio C Hamano
In preparation for implementing narrow/partial clone, the machinery for checking object connectivity used by gc and fsck has been taught that a missing object is OK when it is referenced by a packfile specially marked as coming from trusted repository that promises to make them available on-demand and lazily. * jh/fsck-promisors: gc: do not repack promisor packfiles rev-list: support termination at promisor objects sha1_file: support lazily fetching missing objects introduce fetch-object: fetch one promisor object index-pack: refactor writing of .keep files fsck: support promisor objects as CLI argument fsck: support referenced promisor objects fsck: support refs pointing to promisor objects fsck: introduce partialclone extension extension.partialclone: introduce partial clone extension
2018-02-13Mark messages for translationsAlexander Shopov
Small changes in messages to fit the style and typography of rest. Reuse already translated messages if possible. Do not translate messages aimed at developers of git. Fix unit tests depending on the original string. Use `test_i18ngrep` for tests with translatable strings. Change and verify rest of tests via `make GETTEXT_POISON=1 test`. Signed-off-by: Alexander Shopov <> Signed-off-by: Junio C Hamano <>
2017-12-19Merge branch 'sg/setup-doc-update'Junio C Hamano
Comment update. * sg/setup-doc-update: setup.c: fix comment about order of .git directory discovery
2017-12-07setup.c: fix comment about order of .git directory discoverySZEDER Gábor
Since gitfiles were introduced in b44ebb19e (Add platform-independent .git "symlink", 2008-02-20) the order of checks during .git directory discovery is: gitfile, gitdir, bare repo. However, that commit did only partially update the in-code comment describing this order, missing the last line which still puts gitdir before gitfile. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>