path: root/setup.c
AgeCommit message (Collapse)Author
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 <>
2017-12-05extension.partialclone: introduce partial clone extensionJonathan Tan
Introduce new repository extension option: `extensions.partialclone` See the update to Documentation/technical/repository-version.txt in this patch for more information. Signed-off-by: Jonathan Tan <> Signed-off-by: Junio C Hamano <>
2017-11-13Integrate hash algorithm support with repo setupbrian m. carlson
In future versions of Git, we plan to support an additional hash algorithm. Integrate the enumeration of hash algorithms with repository setup, and store a pointer to the enumerated data in struct repository. Of course, we currently only support SHA-1, so hard-code this value in read_repository_format. In the future, we'll enumerate this value from the configuration. Add a constant, the_hash_algo, which points to the hash_algo structure pointer in the repository global. Note that this is the hash which is used to serialize data to disk, not the hash which is used to display items to the user. The transition plan anticipates that these may be different. We can add an additional element in the future (say, ui_hash_algo) to provide for this case. Include repository.h in cache.h since we now need to have access to these struct and variable definitions. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2017-11-13setup: expose enumerated repo infobrian m. carlson
We enumerate several different items as part of struct repository_format, but then actually set up those values using the global variables we've initialized from them. Instead, let's pass a pointer to the structure down to the code where we enumerate these values, so we can later on use those values directly to perform setup. This technique makes it easier for us to determine additional items about the repository format (such as the hash algorithm) and then use them for setup later on, without needing to add additional global variables. We can't avoid using the existing global variables since they're intricately intertwined with how things work at the moment, but this improves things for the future. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2017-11-09Merge branch 'js/early-config'Junio C Hamano
Correct start-up sequence so that a repository could be placed immediately under the root directory again (which was broken at around Git 2.13). * js/early-config: setup: avoid double slashes when looking for HEAD
2017-11-03setup: avoid double slashes when looking for HEADJeff King
Andrew Baumann reported that when called outside of any Git worktree, `git rev-parse --is-inside-work-tree` eventually tries to access `//HEAD`, i.e. any `HEAD` file in the root directory, but with a double slash. This double slash is not only unintentional, but is allowed by the POSIX standard to have a special meaning. And most notably on Windows, it does, where it refers to a UNC path of the form `//server/share/`. As a consequence, afore-mentioned `rev-parse` call not only looks for the wrong thing, but it also causes serious delays, as Windows will try to access a server called `HEAD`. Let's simply avoid the unintended double slash. Signed-off-by: Jeff King <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2017-10-07Merge branch 'ks/verify-filename-non-option-error-message-tweak'Junio C Hamano
Error message tweak. * ks/verify-filename-non-option-error-message-tweak: setup: update error message to be more meaningful
2017-10-04setup: update error message to be more meaningfulKaartic Sivaraam
The error message shown when a flag is found when expecting a filename wasn't clear as it didn't communicate what was wrong using the 'suitable' words in *all* cases. $ git ls-files test-file Correct case, $ git rev-parse --flags --flags fatal: bad flag '--flags' used after filename Incorrect case, $ git grep "some random regex" -n fatal: bad flag '-n' used after filename The above case is incorrect as "some random regex" isn't a filename in this case. Change the error message to be general and communicative. This results in the following output, $ git rev-parse --flags --flags fatal: option '--flags' must come before non-option arguments $ git grep "some random regex" -n fatal: option '-n' must come before non-option arguments Signed-off-by: Kaartic Sivaraam <> Signed-off-by: Junio C Hamano <>
2017-09-27read_gitfile_gently: clarify return value ownership.Han-Wen Nienhuys
Signed-off-by: Han-Wen Nienhuys <> Signed-off-by: Junio C Hamano <>
2017-09-06set_git_dir: handle feeding gitdir to itselfJeff King
Ideally we'd free the existing gitdir field before assigning the new one, to avoid a memory leak. But we can't do so safely because some callers do the equivalent of: set_git_dir(get_git_dir()); We can detect that case as a noop, but there are even more complicated cases like: set_git_dir(remove_leading_path(worktree, get_git_dir()); where we really do need to do some work, but the original string must remain valid. Rather than put the burden on callers to make a copy of the string (only to free it later, since we'll make a copy of it ourselves), let's solve the problem inside set_git_dir(). We can make a copy of the pointer for the old gitdir, and then avoid freeing it until after we've made our new copy. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-08-02grep: recurse in-process using 'struct repository'Brandon Williams
Convert grep to use 'struct repository' which enables recursing into submodules to be handled in-process. Signed-off-by: Brandon Williams <> Signed-off-by: Junio C Hamano <>
2017-06-24environment: place key repository state in the_repositoryBrandon Williams
Migrate 'git_dir', 'git_common_dir', 'git_object_dir', 'git_index_file', 'git_graft_file', and 'namespace' to be stored in 'the_repository'. Signed-off-by: Brandon Williams <> Signed-off-by: Junio C Hamano <>
2017-06-24setup: add comment indicating a hackBrandon Williams
'GIT_TOPLEVEL_PREFIX_ENVIRONMENT' was added in (b58a68c1c setup: allow for prefix to be passed to git commands) to aid in fixing a bug where 'ls-files' and 'grep' were not able to properly recurse when called from within a subdirectory. Add a 'NEEDSWORK' comment indicating that this envvar should be removed once 'ls-files' and 'grep' can recurse in-process. Signed-off-by: Brandon Williams <> Signed-off-by: Junio C Hamano <>
2017-06-24setup: don't perform lazy initialization of repository stateBrandon Williams
Under some circumstances (bogus GIT_DIR value or the discovered gitdir is '.git') 'setup_git_directory()' won't initialize key repository state. This leads to inconsistent state after running the setup code. To account for this inconsistent state, lazy initialization is done once a caller asks for the repository's gitdir or some other piece of repository state. This is confusing and can be error prone. Instead let's tighten the expected outcome of 'setup_git_directory()' and ensure that it initializes repository state in all cases that would have been handled by lazy initialization. This also lets us drop the requirement to have 'have_git_dir()' check if the environment variable GIT_DIR was set as that will be handled by the end of the setup code. Signed-off-by: Brandon Williams <> Signed-off-by: Junio C Hamano <>
2017-06-24Merge branches 'bw/ls-files-sans-the-index' and 'bw/config-h' into ↵Junio C Hamano
bw/repo-object * bw/ls-files-sans-the-index: ls-files: factor out tag calculation ls-files: factor out debug info into a function ls-files: convert show_files to take an index ls-files: convert show_ce_entry to take an index ls-files: convert prune_cache to take an index ls-files: convert ce_excluded to take an index ls-files: convert show_ru_info to take an index ls-files: convert show_other_files to take an index ls-files: convert show_killed_files to take an index ls-files: convert write_eolinfo to take an index ls-files: convert overlay_tree_on_cache to take an index tree: convert read_tree to take an index parameter convert: convert renormalize_buffer to take an index convert: convert convert_to_git to take an index convert: convert convert_to_git_filter_fd to take an index convert: convert crlf_to_git to take an index convert: convert get_cached_convert_stats_ascii to take an index * bw/config-h: config: don't implicitly use gitdir or commondir config: respect commondir setup: teach discover_git_directory to respect the commondir config: don't include config.h by default config: remove git_config_iter config: create config.h alias: use the early config machinery to expand aliases t7006: demonstrate a problem with aliases in subdirectories t1308: relax the test verifying that empty alias values are disallowed help: use early config when autocorrecting aliases config: report correct line number upon error discover_git_directory(): avoid setting invalid git_dir
2017-06-19Merge branch 'jk/pathspec-magic-disambiguation'Junio C Hamano
The convention for a command line is to follow "git cmdname --options" with revisions followed by an optional "--" disambiguator and then finally pathspecs. When "--" is not there, we make sure early ones are all interpretable as revs (and do not look like paths) and later ones are the other way around. A pathspec with "magic" (e.g. ":/p/a/t/h" that matches p/a/t/h from the top-level of the working tree, no matter what subdirectory you are working from) are conservatively judged as "not a path", which required disambiguation more often. The command line parser learned to say "it's a pathspec" a bit more often when the syntax looks like so. * jk/pathspec-magic-disambiguation: verify_filename(): flip order of checks verify_filename(): treat ":(magic)" as a pathspec check_filename(): handle ":^" path magic check_filename(): use skip_prefix check_filename(): refactor ":/" handling t4208: add check for ":/" without matching file
2017-06-15setup: teach discover_git_directory to respect the commondirBrandon Williams
Currently 'discover_git_directory' only looks at the gitdir to determine if a git directory was discovered. This causes a problem in the event that the gitdir which was discovered was in fact a per-worktree git directory and not the common git directory. This is because the repository config, which is checked to verify the repository's format, is stored in the commondir and not in the per-worktree gitdir. Correct this behavior by checking the config stored in the commondir. It will also be of use for callers to have access to the commondir, so lets also return that upon successfully discovering a git directory. Signed-off-by: Brandon Williams <> Signed-off-by: Junio C Hamano <>