src/repository.c


Log

Author Commit Date CI Message
Edward Thomson ac77d306 2021-04-13T17:00:37 Merge pull request #5834 from libgit2/cmn/repo-no-passthrough repo: remove an inappropriate use of PASSTHROUGH
Carlos Martín Nieto 631fe56f 2021-04-11T21:22:33 repo: specify init.defaultbranch is meant to be a branch name We don't want the default branch's refname here but its name as branch. Returning an error saying it's not a valid reference here suggests we want the value of `init.defaultbranch` to be something like `refs/heads/default` which is not the case.
Carlos Martín Nieto 6591deef 2021-04-11T14:27:14 repo: remove an inappropriate use of PASSTHROUGH This error code is for callbacks where we should act as though the callback was not set. This is not something that makes sense for a `_foreach` and checking for that error message to bubble up mostly is happenstance precisely because this is not an error code we expect in the callback. As part of removing this, let's also remove a use of foreach as we can open-code this check.
Ian Hattendorf 7891e153 2021-04-01T11:34:38 Default to GIT_BRANCH_DEFAULT if init.defaultBranch is empty string We already do this in repo_init_head
Edward Thomson 3f4bc213 2021-01-07T14:05:02 repo: ignore empty init.defaultbranch The init.defaultbranch option may be set, but empty. In this case, we should ignore it instead of trying to set our default branch to `refs/heads/`.
lhchavez 1ab2f577 2020-12-11T05:13:16 Fix an oops
lhchavez 6cd0c853 2020-12-11T05:08:45 Small refactor to make thing tidier Also repurposed an unused function and deleted another one.
Edward Thomson ab772974 2020-12-05T15:49:30 threads: give atomic functions the git_atomic prefix
lhchavez 4ae41f9c 2020-08-02T16:26:25 Make the odb race-free This change adds all the necessary locking to the odb to avoid races in the backends. Part of: #5592
Edward Thomson 36adde56 2020-04-05T21:17:42 repository: use GIT_ASSERT
Edward Thomson cb4bfbc9 2020-04-05T11:07:54 buffer: git_buf_sanitize should return a value `git_buf_sanitize` is called with user-input, and wants to sanity-check that input. Allow it to return a value if the input was malformed in a way that we cannot cope.
Edward Thomson b52bb4d4 2020-10-11T13:20:52 refs: use git_reference_name_is_valid
Eric Huss 5b7e7131 2020-10-07T15:54:08 Fix error return for invalid extensions.
Edward Thomson 84d2a035 2020-07-13T10:10:02 repo: teach isempty about default branch config The git_repository_isempty function now respects the init.defaultbranch setting (instead of hardcoding "master") to understand if a repository is empty or not.
Edward Thomson 4cc3b2cb 2020-07-13T10:08:23 repo: add git_repository_initialbranch Provide a helper function to get the initial branch for a repository, respecting the `init.defaultBranch` configuration option, if set, and returning the "default default" (currently `master`) otherwise.
Edward Thomson e411aae3 2020-07-13T08:47:15 repo: honor the init.defaultBranch setting As part of a push towards more inclusive language, git is reconsidering using "master" as the default branch name. As a first step, this setting will be configurable with the `init.defaultBranch` configuration option. Honor this during repository initialization. During initialization, we will create an initial branch: 1. Using the `initial_head` setting, if specified; 2. Using the `HEAD` configured in a template, if it exists; 3. Using the `init.defaultBranch` configuration option, if it is set; or 4. Using `master` in the absence of additional configuration.
Patrick Steinhardt 65895410 2020-06-17T14:56:36 repository: retrieve worktree HEAD via refdb The function `git_repository_head_for_worktree` currently uses `git_reference__read_head` to directly read a given worktree's HEAD from the filesystem. This is broken in case the repository uses a different refdb implementation than the filesystem-based one, so let's instead open the worktree as a real repository and use `git_reference_lookup`. This also fixes the case where the worktree's HEAD is not a symref, but a detached HEAD, which would have resulted in an error previously.
Patrick Steinhardt d1f210fc 2020-06-17T15:09:49 repository: remove function to iterate over HEADs The function `git_repository_foreach_head` is broken, as it directly interacts with the on-disk representation of the reference database, thus assuming that no other refdb is used for the given repository. As this is an internal function only and all users have been replaced, let's remove this function.
Patrick Steinhardt 2fcb4f28 2020-06-17T14:09:04 repository: introduce new function to iterate over all worktrees Given a Git repository, it's non-trivial to iterate over all worktrees that are associated with it, including the "main" repository. This commit adds a new internal function `git_repository_foreach_worktree` that does this for us.
Patrick Steinhardt c6184f0c 2020-06-08T21:07:36 tree-wide: do not compile deprecated functions with hard deprecation When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h" header to be empty. As a result, no function declarations are made available to callers, but the implementations are still available to link against. This has the problem that function declarations also aren't visible to the implementations, meaning that the symbol's visibility will not be set up correctly. As a result, the resulting library may not expose those deprecated symbols at all on some platforms and thus cause linking errors. Fix the issue by conditionally compiling deprecated functions, only. While it becomes impossible to link against such a library in case one uses deprecated functions, distributors of libgit2 aren't expected to pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real" hard deprecation still makes sense in the context of CI to test we don't use deprecated symbols ourselves and in case a dependant uses libgit2 in a vendored way and knows it won't ever use any of the deprecated symbols anyway.
Edward Thomson 51eff5a5 2020-05-29T13:13:19 strarray: we should `dispose` instead of `free` We _dispose_ the contents of objects; we _free_ objects (and their contents). Update `git_strarray_free` to be `git_strarray_dispose`. `git_strarray_free` remains as a deprecated proxy function.
Patrick Steinhardt dfd7fcc4 2020-04-02T13:26:13 Merge pull request #5388 from bk2204/repo-format-v1 Handle repository format v1
brian m. carlson 06f02300 2020-02-07T00:33:52 repository: handle format v1 Git has supported repository format version 1 for some time. This format is just like version 0, but it supports extensions. Implementations must reject extensions that they don't support. Add support for this format version and reject any extensions but extensions.noop, which is the only extension we currently support. While we're at it, also clean up an error message.
Patrick Steinhardt 2288a713 2020-02-07T12:15:34 repository: check error codes when reading common link When checking whether a path is a valid repository path, we try to read the "commondir" link file. In the process, we neither confirm that constructing the file's path succeeded nor do we verify that reading the file succeeded, which might cause us to verify repositories on an empty or bogus path later on. Fix this by checking return values. As the function to verify repos doesn't currently support returning errors, this commit also refactors the function to return an error code, passing validity of the repo via an out parameter instead, and adjusts all existing callers.
Edward Thomson a3126a72 2020-01-18T17:50:38 repository functions: return an int Stop returning a void for functions, future-proofing them to allow them to fail.
Sven Strickroth 470a05d0 2020-01-16T17:53:50 Do not return free'd git_repository object on error Regression introduced in commit dde6d9c706bf1ecab545da55ab874a016587af1f. This issue causes lots of crashes in TortoiseGit. Signed-off-by: Sven Strickroth <email@cs-ware.de>
Edward Thomson fb2198db 2019-06-23T16:23:59 futils_filesize: use `uint64_t` for object size Instead of using a signed type (`off_t`) use `uint64_t` for the maximum size of files.
Sebastian Henke 3335a034 2019-10-10T15:28:46 refs: fix locks getting forcibly removed The flag GIT_FILEBUF_FORCE currently does two things: 1. It will cause the filebuf to create non-existing leading directories for the file that is about to be written. 2. It will forcibly remove any pre-existing locks. While most call sites actually do want (1), they do not want to remove pre-existing locks, as that renders the locking mechanisms effectively useless. Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to separate both behaviours cleanly from each other and convert callers to use it instead of `GIT_FILEBUF_FORCE` to have them honor locked files correctly. As this conversion removes all current users of `GIT_FILEBUF_FORCE`, this commit removes the flag altogether.
Laurence McGlashan dde6d9c7 2019-09-10T17:09:57 open:move all cleanup code to cleanup label in git_repository_open_ext
Laurence McGlashan b545be3d 2019-09-10T11:14:36 open:fix memory leak when passing NULL to git_repository_open_ext
Patrick Steinhardt ded77bb1 2019-06-29T09:58:34 path: extract function to check whether a path supports symlinks When initializing a repository, we need to check whether its working directory supports symlinks to correctly set the initial value of the "core.symlinks" config variable. The code to check the filesystem is reusable in other parts of our codebase, like for example in our tests to determine whether certain tests can be expected to succeed or not. Extract the code into a new function `git_path_supports_symlinks` to avoid duplicate implementations. Remove a duplicate implementation in the repo test helper code.
Patrick Steinhardt e54343a4 2019-06-29T09:17:32 fileops: rename to "futils.h" to match function signatures Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
Edward Thomson 964c1c60 2019-07-20T11:02:30 Merge pull request #5176 from pks-t/pks/repo-template-head repository: do not initialize HEAD if it's provided by templates
Patrick Steinhardt 9d46f167 2019-07-19T10:50:51 repository: do not initialize HEAD if it's provided by templates When using templates to initialize a git repository, then git-init(1) will copy over all contents of the template directory. These will be preferred over the default ones created by git-init(1). While we mostly do the same, there is the exception of "HEAD". While we do copy over the template's HEAD file, afterwards we'll immediately re-initialize its contents with either the default "ref: refs/origin/master" or the init option's `initial_head` field. Let's fix the inconsistency with upstream git-init(1) by not overwriting the template HEAD, but only if the user hasn't set `opts.initial_head`. If the `initial_head` field has been supplied, we should use that indifferent from whether the template contained a HEAD file or not. Add tests to verify we correctly use the template directory's HEAD file and that `initial_head` overrides the template.
Patrick Steinhardt f3134a84 2019-07-19T10:41:10 repository: update error handling in `init_ext` Update `git_repository_init_ext` to use our typical style of error handling. The function had multiple statements which didn't `goto out` immediately but instead deferred it to later calls combined with `if` statements.
Patrick Steinhardt 869ae5a3 2019-07-19T10:15:43 repository: avoid swallowing error codes in `create_head` The error handling in `git_repository_create_head` completely swallows all error codes. While probably not too much of a problem, this also violates our usual coding style. Refactor the code to use a local `error` variable with the typical `goto out` statements.
Patrick Steinhardt 658022c4 2019-07-18T13:53:41 configuration: cvar -> configmap `cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
Etienne Samson 501c51b2 2019-06-26T14:49:50 repo: commondir resolution can sometimes fallback to the repodir For example, https://git-scm.com/docs/gitrepository-layout says: info Additional information about the repository is recorded in this directory. This directory is ignored if $GIT_COMMON_DIR is set and "$GIT_COMMON_DIR/info" will be used instead. So when looking for `info/attributes`, we need to check the commondir first, or fallback to "our" `info/attributes`.
Edward Thomson fc3a94ba 2019-05-20T07:13:42 repository: use size_t for length
Edward Thomson 0b5ba0d7 2019-06-06T16:36:23 Rename opt init functions to `options_init` In libgit2 nomenclature, when we need to verb a direct object, we name a function `git_directobject_verb`. Thus, if we need to init an options structure named `git_foo_options`, then the name of the function that does that should be `git_foo_options_init`. The previous names of `git_foo_init_options` is close - it _sounds_ as if it's initializing the options of a `foo`, but in fact `git_foo_options` is its own noun that should be respected. Deprecate the old names; they'll now call directly to the new ones.
Erik Aigner 9cc904da 2019-05-23T10:49:44 repository: fix garbage return value error was never initialized and a garbage value returned on success.
Edward Thomson 4069f924 2019-02-22T10:56:08 Merge pull request #4901 from pks-t/pks/uniform-map-api High-level map APIs
Patrick Steinhardt bbdcd450 2019-02-20T10:40:06 cache: fix misnaming of `git_cache_free` Functions that free a structure's contents but not the structure itself shall be named `dispose` in the libgit2 project, but the function `git_cache_free` does not follow this naming pattern. Fix this by renaming it to `git_cache_dispose` and adjusting all callers to make use of the new name.
Patrick Steinhardt 351eeff3 2019-01-23T10:42:46 maps: use uniform lifecycle management functions Currently, the lifecycle functions for maps (allocation, deallocation, resize) are not named in a uniform way and do not have a uniform function signature. Rename the functions to fix that, and stick to libgit2's naming scheme of saying `git_foo_new`. This results in the following new interface for allocation: - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an error code if we ran out of memory - `void git_<t>map_free(git_<t>map *map)` to free a map - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map This commit also fixes all existing callers.
Patrick Steinhardt efb20825 2019-02-14T13:05:49 branches: introduce flag to skip enumeration of certain HEADs Right now, the function `git_repository_foreach_head` will always iterate over all HEADs of the main repository and its worktrees. In some cases, it might be required to skip either of those, though. Add a flag in preparation for the following commit that enables this behaviour.
Edward Thomson f673e232 2018-12-27T13:47:34 git_error: use new names in internal APIs and usage Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson b8b796c1 2019-01-20T18:09:43 repository: free memory in symlink detection function
Edward Thomson ed8cfbf0 2019-01-17T00:32:31 references: use new names in internal usage Update internal usage to use the `git_reference` names for constants.
Edward Thomson 168fe39b 2018-11-28T14:26:57 object_type: use new enumeration names Use the new object_type enumeration names within the codebase.
Edward Thomson 18e71e6d 2018-11-28T13:31:06 index: use new enum and structure names Use the new-style index names throughout our own codebase.
Patrick Steinhardt 0ddc6094 2018-11-30T09:46:14 Merge pull request #4770 from tiennou/feature/merge-analysis-any-branch Allow merge analysis against any reference
Sven Strickroth f0714daf 2018-11-25T13:36:29 Fix warning C4133 incompatible types in MSVC Introduced in commit b433a22a979ae78c28c8b16f8c3487e2787cb73e. Signed-off-by: Sven Strickroth <email@cs-ware.de>
Edward Thomson 820e1e93 2018-10-20T02:17:22 repository: load_config for non-repo configs Teach `load_config` how to load all the configurations except (optionally) the repository configuration. This allows the new repository codepath to load the global/xdg/system configuration paths so that they can be inspected during repository initialization.
Edward Thomson b433a22a 2018-10-19T03:14:53 win32: emulate Git for Windows in symlink support Emulate the Git for Windows `core.symlinks` support. Since symbolic links are generally enabled for Administrator (and _may_ be enabled due to enabling Developer mode) but symbolic links are still sufficiently uncommon on Windows that Git users are expected to explicitly opt-in to symbolic links by enabling `core.symlinks=true` in a global (or xdg or system) configuration. When `core.symlinks=true` is set globally _and_ symbolic links support is detected then new repositories created will not have a `core.symlinks` set. If `core.symlinks` is _not_ set then no detection will be performed, and `core.symlinks=false` will be set in the repository configuration.
Etienne Samson 5c0c8fdd 2018-08-17T02:07:38 repository: assert that we're passed a valid head pointer
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Etienne Samson c7964c22 2018-04-18T22:40:46 repository: being a worktree means we're not really bare We were previously conflating any error into GIT_ENOTFOUND, which might or might not be correct. This fixes the code so a config error is bubbled up, as well as preserving the semantics in the face of worktree-repositories
Patrick Steinhardt 585b5dac 2017-11-18T15:43:11 refcount: make refcounting conform to aliasing rules Strict aliasing rules dictate that for most data types, you are not allowed to cast them to another data type and then access the casted pointers. While this works just fine for most compilers, technically we end up in undefined behaviour when we hurt that rule. Our current refcounting code makes heavy use of casting and thus violates that rule. While we didn't have any problems with that code, Travis started spitting out a lot of warnings due to a change in their toolchain. In the refcounting case, the code is also easy to fix: as all refcounting-statements are actually macros, we can just access the `rc` field directly instead of casting. There are two outliers in our code where that doesn't work. Both the `git_diff` and `git_patch` structures have specializations for generated and parsed diffs/patches, which directly inherit from them. Because of that, the refcounting code is only part of the base structure and not of the children themselves. We can help that by instead passing their base into `GIT_REFCOUNT_INC`, though.
Patrick Steinhardt 529e873c 2017-05-23T11:51:00 config: pass repository when opening config files Our current configuration logic is completely oblivious of any repository, but only cares for actual file paths. Unfortunately, we are forced to break this assumption by the introduction of conditional includes, which are evaluated in the context of a repository. Right now, only one conditional exists with "gitdir:" -- it will only include the configuration if the current repository's git directory matches the value passed to "gitdir:". To support these conditionals, we have to break our API and make the repository available when opening a configuration file. This commit extends the `open` call of configuration backends to include another repository and adjusts existing code to have it available. This includes the user-visible functions `git_config_add_file_ondisk` and `git_config_add_backend`.
Patrick Steinhardt d02cf564 2017-05-23T12:56:41 repository: constify several repo parameters for getters Several functions to retrieve variables from a repository only return immutable values, which allows us to actually constify the passed-in repository parameter. Do so to help a later patch, which will only have access to a constant repository.
Patrick Steinhardt 0c7f49dd 2017-06-30T13:39:01 Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
Ariel Davis af720bb6 2017-06-16T23:19:31 repository: remove trailing whitespace
Ariel Davis 9a46c777 2017-06-16T21:02:26 repository: do not initialize templates if dir is an empty string
Edward Thomson 2d486781 2017-06-12T12:02:27 repository: don't fail to create config option in inmemory repo When in an in-memory repository - without a configuration file - do not fail to create a configuration object.
Edward Thomson 9d49a43c 2017-06-12T12:01:10 repository_item_path: return ENOTFOUND when appropriate Disambiguate error values: return `GIT_ENOTFOUND` when the item cannot exist in the repository (perhaps because the repository is inmemory or otherwise not backed by a filesystem), return `-1` when there is a hard failure.
Edward Thomson fb3fc837 2017-06-12T11:45:09 repository_item_path: error messages lowercased
Patrick Steinhardt 6c23704d 2017-06-08T21:40:18 settings: rename `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION` Initially, the setting has been solely used to enable the use of `fsync()` when creating objects. Since then, the use has been extended to also cover references and index files. As the option is not yet part of any release, we can still correct this by renaming the option to something more sensible, indicating not only correlation to objects. This commit renames the option to `GIT_OPT_ENABLE_FSYNC_GITDIR`. We also move the variable from the object to repository source code.
Edward Thomson 04de614b 2017-06-04T19:03:07 Merge pull request #4243 from pks-t/pks/submodule-workdir Submodule working directory
Carlos Martín Nieto e694e4e9 2017-05-20T14:17:36 Merge pull request #4174 from libgit2/ethomson/set_head_to_tag git_repository_set_head: use tag name in reflog
Patrick Steinhardt 2696c5c3 2017-05-19T09:21:17 repository: make check if repo is a worktree more strict To determine if a repository is a worktree or not, we currently check for the existence of a "gitdir" file inside of the repository's gitdir. While this is sufficient for non-broken repositories, we have at least one case of a subtly broken repository where there exists a gitdir file inside of a gitmodule. This will cause us to misidentify the submodule as a worktree. While this is not really a fault of ours, we can do better here by observing that a repository can only ever be a worktree iff its common directory and dotgit directory are different. This allows us to make our check whether a repo is a worktree or not more strict by doing a simple string comparison of these two directories. This will also allow us to do the right thing in the above case of a broken repository, as for submodules these directories will be the same. At the same time, this allows us to skip the `stat` check for the "gitdir" file for most repositories.
Patrick Steinhardt 9f9fd05f 2017-05-19T08:59:46 repository: factor out worktree check The check whether a repository is a worktree or not is currently done inside of `git_repository_open_ext`. As we want to extend this function later on, pull it out into its own function `repo_is_worktree` to ease working on it.
Patrick Steinhardt 32841973 2017-05-19T08:38:47 repository: improve parameter names for `find_repo` The out-parameters of `find_repo` containing found paths of a repository are a tad confusing, as they are not as obvious as they could be. Rename them like following to ease reading the code: - `repo_path` -> `gitdir_path` - `parent_path` -> `workdir_path` - `link_path` -> `gitlink_path` - `common_path` -> `commondir_path`
Patrick Steinhardt 57121a23 2017-05-19T08:34:32 repository: clear out-parameter instead of freeing it The `path` out-parameter of `find_repo` is being sanitized initially such that we do not try to append to existing content. The sanitization is done via `git_buf_free`, though, which forces us to needlessly reallocate the buffer later in the function. Fix this by using `git_buf_clear` instead.
Edward Thomson be343b88 2017-05-01T18:56:55 worktrees: cleanup some memory leaks Be sure to clean up looked up references. Free buffers instead of merely clearing them. Use `git__free` instead of `free`.
Patrick Steinhardt 74511aa2 2017-04-04T18:44:29 repository: add function to iterate over all HEADs While we already provide functions to get the current repository's HEAD, it is quite involved to iterate over HEADs of both the repository and all linked work trees. This commit implements a function `git_repository_foreach_head`, which accepts a callback which is then called for all HEAD files.
Patrick Steinhardt 3e84aa50 2017-04-05T13:47:09 repository: get worktree HEAD via `git_reference__read_head` The functions `git_repository_head_for_worktree` and `git_repository_detached_head_for_worktree` both implement their own logic to read the HEAD reference file. Use the new function `git_reference__read_head` instead to unify the code paths.
Patrick Steinhardt 987f5659 2017-04-04T17:12:22 repository: extract function to get path to a file in a work tree The function `read_worktree_head` has the logic embedded to construct the path to `HEAD` in the work tree's git directory, which is quite useful for other callers. Extract the logic into its own function to make it reusable by others.
Patrick Steinhardt 8242cc1a 2017-04-04T18:18:45 repository: set error message if trying to set HEAD to a checked out one If trying to set the HEAD of a repository to another reference, we have to check whether this reference is already checked out in another linked work tree. If it is, we will refuse setting the HEAD and return an error, but do not set a meaningful error message. Add one.
Edward Thomson e86d02f9 2017-04-03T00:10:47 git_repository_set_head: use remote name in reflog When `git_repository_set_head` is provided a remote reference, update the reflog with the tag name, like we do with a branch. This helps consumers match the semantics of `git checkout remote`.
Edward Thomson ea3bb5c0 2017-03-21T18:12:02 git_repository_set_head: use tag name in reflog When `git_repository_set_head` is provided a tag reference, update the reflog with the tag name, like we do with a branch. This helps consumers match the semantics of `git checkout tag`.
Edward Thomson 1c04a96b 2017-02-28T12:29:29 Honor `core.fsyncObjectFiles`
Patrick Steinhardt 13c3bc9a 2017-01-27T14:32:23 strmap: remove GIT__USE_STRMAP macro
Patrick Steinhardt 39abd3ad 2016-11-04T13:39:54 worktree: compute workdir for worktrees opened via their gitdir When opening a worktree via the gitdir of its parent repository we fail to correctly set up the worktree's working directory. The problem here is two-fold: we first fail to see that the gitdir actually is a gitdir of a working tree and then subsequently fail to determine the working tree location from the gitdir. The first problem of not noticing a gitdir belongs to a worktree can be solved by checking for the existence of a `gitdir` file in the gitdir. This file points back to the gitlink file located in the working tree's working directory. As this file only exists for worktrees, it should be sufficient indication of the gitdir belonging to a worktree. The second problem, that is determining the location of the worktree's working directory, can then be solved by reading the `gitdir` file in the working directory's gitdir. When we now resolve relative paths and strip the final `.git` component, we have the actual worktree's working directory location.
Patrick Steinhardt 84f56cb0 2016-11-04T11:59:52 repository: rename `path_repository` and `path_gitlink` The `path_repository` variable is actually confusing to think about, as it is not always clear what the repository actually is. It may either be the path to the folder containing worktree and .git directory, the path to .git itself, a worktree or something entirely different. Actually, the intent of the variable is to hold the path to the gitdir, which is either the .git directory or the bare repository. Rename the variable to `gitdir` to avoid confusion. While at it, also rename `path_gitlink` to `gitlink` to improve consistency.
Patrick Steinhardt 384518d0 2015-10-27T14:17:52 repository: restrict checking out checked out branches If a branch is already checked out in a working tree we are not allowed to check out that branch in another repository. Introduce this restriction when setting a repository's HEAD.
Patrick Steinhardt 04fb12ab 2015-10-27T12:37:51 worktree: implement functions reading HEAD Implement `git_repository_head_for_worktree` and `git_repository_head_detached_for_worktree` for directly accessing a worktree's HEAD without opening it as a `git_repository` first.
Patrick Steinhardt 8c8d726e 2015-10-21T12:10:30 worktree: implement `git_repository_open_from_worktree` Add function `git_repository_open_from_worktree`, which allows to open a `git_worktree` as repository.
Patrick Steinhardt 854b5c70 2015-10-26T16:21:09 repository: expose `repo_init_create_head` Expose the function `repo_init_create_head` as `git_repository_create_head`.
Patrick Steinhardt 4292837d 2015-09-24T14:37:10 config: open configuration in commondir A repository's configuartion file can always be found in the GIT_COMMON_DIR, which has been newly introduced. For normal repositories this does change nothing, but for working trees this change allows to access the shared configuration file.
Patrick Steinhardt 79ab3ef6 2015-10-15T15:58:05 repository: introduce is_worktree variable
Patrick Steinhardt c5f3da96 2016-11-11T14:36:43 repository: use `git_repository_item_path` The recent introduction of the commondir variable of a repository requires callers to distinguish whether their files are part of the dot-git directory or the common directory shared between multpile worktrees. In order to take the burden from callers and unify knowledge on which files reside where, the `git_repository_item_path` function has been introduced which encapsulate this knowledge. Modify most existing callers of `git_repository_path` to use `git_repository_item_path` instead, thus making them implicitly aware of the common directory.
Patrick Steinhardt cb3269c9 2016-11-11T13:46:59 repository: add function to retrieve paths for repo items
Patrick Steinhardt c09fd54e 2015-09-16T12:10:11 repository: introduce commondir variable The commondir variable stores the path to the common directory. The common directory is used to store objects and references shared across multiple repositories. A current use case is the newly introduced `git worktree` feature, which sets up a separate working copy, where the backing git object store and references are pointed to by the common directory.
Brock Peabody 4d99c4cf 2016-11-23T18:32:48 Allow for caching of submodules. Added `git_repository_submodule_cache_all` to initialze a cache of submodules on the repository so that operations looking up N submodules are O(N) and not O(N^2). Added a `git_repository_submodule_cache_clear` function to remove the cache. Also optimized the function that loads all submodules as it was itself O(N^2) w.r.t the number of submodules, having to loop through the `.gitmodules` file once per submodule. I changed it to process the `.gitmodules` file once, into a map. Signed-off-by: David Turner <dturner@twosigma.com>
Edward Thomson 909d5494 2016-12-29T12:25:15 giterr_set: consistent error messages Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
Patrick Steinhardt 0f316096 2016-11-11T16:55:33 repository: do not interpret all files as gitlinks in discovery When trying to find a discovery, we walk up the directory structure checking if there is a ".git" file or directory and, if so, check its validity. But in the case that we've got a ".git" file, we do not want to unconditionally assume that the file is in fact a ".git" file and treat it as such, as we would error out if it is not. Fix the issue by only treating a file as a gitlink file if it ends with "/.git". This allows users of the function to discover a repository by handing in any path contained inside of a git repository.
Josh Triplett c9e967a1 2016-11-10T03:51:12 git_repository_open_ext: fix handling of $GIT_NAMESPACE The existing code would set a namespace of "" (empty string) with GIT_NAMESPACE unset. In a repository where refs/heads/namespaces/ exists, that can produce incorrect results. Detect that case and avoid setting the namespace at all. Since that makes the last assignment to error conditional, and the previous assignment can potentially get GIT_ENOTFOUND, set error to 0 explicitly to prevent the call from incorrectly failing with GIT_ENOTFOUND.
Edward Thomson b118f647 2016-07-22T14:02:00 repository: don't cast to `int` for no reason And give it a default so that some compilers don't (unnecessarily) complain.
Josh Triplett 2b490284 2016-06-24T15:59:37 find_repo: Clean up and simplify logic find_repo had a complex loop and heavily nested conditionals, making it difficult to follow. Simplify this as much as possible: - Separate assignments from conditionals. - Check the complex loop condition in the only place it can change. - Break out of the loop on error, rather than going through the rest of the loop body first. - Handle error cases by immediately breaking, rather than nesting conditionals. - Free repo_link unconditionally on the way out of the function, rather than in multiple places. - Add more comments on the remaining complex steps.
Josh Triplett 0dd98b69 2016-04-03T17:22:07 Add GIT_REPOSITORY_OPEN_FROM_ENV flag to respect $GIT_* environment vars git_repository_open_ext provides parameters for the start path, whether to search across filesystems, and what ceiling directories to stop at. git commands have standard environment variables and defaults for each of those, as well as various other parameters of the repository. To avoid duplicate environment variable handling in users of libgit2, add a GIT_REPOSITORY_OPEN_FROM_ENV flag, which makes git_repository_open_ext automatically handle the appropriate environment variables. Commands that intend to act just like those built into git itself can use this flag to get the expected default behavior. git_repository_open_ext with the GIT_REPOSITORY_OPEN_FROM_ENV flag respects $GIT_DIR, $GIT_DISCOVERY_ACROSS_FILESYSTEM, $GIT_CEILING_DIRECTORIES, $GIT_INDEX_FILE, $GIT_NAMESPACE, $GIT_OBJECT_DIRECTORY, and $GIT_ALTERNATE_OBJECT_DIRECTORIES. In the future, when libgit2 gets worktree support, git_repository_open_env will also respect $GIT_WORK_TREE and $GIT_COMMON_DIR; until then, git_repository_open_ext with this flag will error out if either $GIT_WORK_TREE or $GIT_COMMON_DIR is set.