aboutsummaryrefslogtreecommitdiff
path: root/repository.c
Commit message (Collapse)AuthorAge
* repository: pre-initialize hash algo pointerbrian m. carlson2018-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | There are various git subcommands (among them, clone) which don't set up the repository (that is, they lack RUN_SETUP or RUN_SETUP_GENTLY) but end up needing to have information about the hash algorithm in use. Because the hash algorithm is part of struct repository and it's only initialized in repository setup, we can end up dereferencing a NULL pointer in some cases if we call one of these subcommands and look up the empty blob or empty tree values. A "git clone" of a project that has two paths that differ only in case suffers from this if it is run on a case insensitive platform. When the command attempts to check out one of these two paths after checking out the other one, the checkout codepath needs to see if the version that is already on the filesystem (which should not happen if the FS were case sensitive) is dirty, and it needs to exercise the hashing code at that point. In the future, we can add a command line option for this or read it from the configuration, but until we're ready to expose that functionality to the user, simply initialize the repository structure to use the current hash algorithm, SHA-1. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* repository: fix a sparse 'using integer as NULL pointer' warningRamsay Jones2017-11-28
| | | | | | | | | | | | | Commit 78a6766802 ("Integrate hash algorithm support with repo setup", 2017-11-12) added a 'const struct git_hash_algo *hash_algo' field to the repository structure, without modifying the initializer of the 'the_repo' variable. This does not actually introduce a bug, since the '0' initializer for the 'ignore_env:1' bit-field is interpreted as a NULL pointer (hence the warning), and the final field (now with no initializer) receives a default '0'. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Integrate hash algorithm support with repo setupbrian m. carlson2017-11-13
| | | | | | | | | | | | | | | | | | | | | | 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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* repository: use FREE_AND_NULLRené Scharfe2017-10-02
| | | | | | | | | | | Use the macro FREE_AND_NULL to release allocated objects and clear their pointers. This is shorter and documents the intent better by combining the two related operations into one. Patch generated with Coccinelle and contrib/coccinelle/free.cocci. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* set_git_dir: handle feeding gitdir to itselfJeff King2017-09-06
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* repository: free fields before overwriting themJeff King2017-09-06
| | | | | | | | | | | | | | | | It's possible that the repository data may be initialized twice (e.g., after doing a chdir() to the top of the worktree we may have to adjust a relative git_dir path). We should free() any existing fields before assigning to them to avoid leaks. This should be safe, as the fields are set based on the environment or on other strings like the gitdir or commondir. That makes it impossible that we are feeding an alias to the just-freed string. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'bw/grep-recurse-submodules'Junio C Hamano2017-08-22
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git grep --recurse-submodules" has been reworked to give a more consistent output across submodule boundary (and do its thing without having to fork a separate process). * bw/grep-recurse-submodules: grep: recurse in-process using 'struct repository' submodule: merge repo_read_gitmodules and gitmodules_config submodule: check for unmerged .gitmodules outside of config parsing submodule: check for unstaged .gitmodules outside of config parsing submodule: remove fetch.recursesubmodules from submodule-config parsing submodule: remove submodule.fetchjobs from submodule-config parsing config: add config_from_gitmodules cache.h: add GITMODULES_FILE macro repository: have the_repository use the_index repo_read_index: don't discard the index
| * repository: have the_repository use the_indexBrandon Williams2017-07-18
| | | | | | | | | | | | | | | | | | | | Have the index state which is stored in 'the_repository' be a pointer to the in-core index 'the_index'. This makes it easier to begin transitioning more parts of the code base to operate on a 'struct repository'. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * repo_read_index: don't discard the indexBrandon Williams2017-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | Have 'repo_read_index()' behave more like the other read_index family of functions and don't discard the index if it has already been populated and instead rely on the quick return of read_index_from which has: /* istate->initialized covers both .git/index and .git/sharedindex.xxx */ if (istate->initialized) return istate->cache_nr; Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | submodule: convert submodule config lookup to use object_idbrian m. carlson2017-07-17
|/ | | | | Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* repository: enable initialization of submodulesBrandon Williams2017-06-23
| | | | | | | | | | | | | | | | | | | | | Introduce 'repo_submodule_init()' which performs initialization of a 'struct repository' as a submodule of another 'struct repository'. The resulting submodule 'struct repository' can be in one of three states: 1. The submodule is initialized and has a worktree. 2. The submodule is initialized but does not have a worktree. This would occur when the submodule's gitdir is present in the superproject's 'gitdir/modules/' directory yet the submodule has not been checked out in superproject's worktree. 3. The submodule remains uninitialized due to an error in the initialization process or there is no matching submodule at the provided path in the superproject. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* submodule-config: store the_submodule_cache in the_repositoryBrandon Williams2017-06-23
| | | | | | | | | Refactor how 'the_submodule_cache' is handled so that it can be stored inside of a repository object. Also migrate 'the_submodule_cache' to be stored in 'the_repository'. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* repository: add index_state to struct repoBrandon Williams2017-06-23
| | | | | Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* config: read config from a repository objectBrandon Williams2017-06-23
| | | | | | | | | | | | | | | | | | | | | | | Teach the config machinery to read config information from a repository object. This involves storing a 'struct config_set' inside the repository object and adding a number of functions (repo_config*) to be able to query a repository's config. The current config API enables lazy-loading of the config. This means that when 'git_config_get_int()' is called, if the_config_set hasn't been populated yet, then it will be populated and properly initialized by reading the necessary config files (system wide .gitconfig, user's home .gitconfig, and the repository's config). To maintain this paradigm, the new API to read from a repository object's config will also perform this lazy-initialization. Since both APIs (git_config_get* and repo_config_get*) have the same semantics we can migrate the default config to be stored within 'the_repository' and just have the 'git_config_get*' family of functions redirect to the 'repo_config_get*' functions. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* repository: introduce the repository objectBrandon Williams2017-06-23
Introduce the repository object 'struct repository' which can be used to hold all state pertaining to a git repository. Some of the benefits of object-ifying a repository are: 1. Make the code base more readable and easier to reason about. 2. Allow for working on multiple repositories, specifically submodules, within the same process. Currently the process for working on a submodule involves setting up an argv_array of options for a particular command and then launching a child process to execute the command in the context of the submodule. This is clunky and can require lots of little hacks in order to ensure correctness. Ideally it would be nice to simply pass a repository and an options struct to a command. 3. Eliminating reliance on global state will make it easier to enable the use of threading to improve performance. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>