src/repository.c


Log

Author Commit Date CI Message
Dimitris Apostolou 90df4302 2022-01-05T12:18:05 Fix typos
Edward Thomson f9c4dc10 2021-11-22T11:23:50 Merge pull request #6106 from ammgws/fixtemplateerr Fix repo init when template dir is non-existent
Edward Thomson 3461aaf7 2021-11-22T10:29:29 repo: minor formatting fix
Jason Nader 709b1b62 2021-11-05T02:28:37 repository: do not copy templates if dir nonexistent This mimics the behaviour of git which just prints a warning and continues with the repo initialisation.
Edward Thomson 62251409 2021-11-01T21:09:17 fs_path: add length with suffix validation
Edward Thomson 91246ee5 2021-11-01T20:14:34 path: use new length validation functions
Edward Thomson 95117d47 2021-10-31T09:45:46 path: separate git-specific path functions from util Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
Edward Thomson f0e693b1 2021-09-07T17:53:49 str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Edward Thomson 0f4256b8 2021-09-24T15:23:34 repository: improve `hashfile` for absolute paths When `git_repository_hashfile` is handed an absolute path, it determines whether the path is within the repository's working directory or not. This is necessary when there is no `as_path` specified. If the path is within the working directory, then the given path should be used for attribute lookups (it is the effective `as_path`). If it is not within the working directory, then it is _not_ eligible. Importantly, now we will _never_ pass an absolute path down to attribute lookup functions.
Edward Thomson 4f24a932 2021-09-14T07:45:50 Merge pull request #6031 from libgit2/ethomson/extensions Support custom git extensions
punkymaniac 379c4646 2021-09-09T19:49:04 Fix coding style for pointer Make some syntax change to follow coding style.
Edward Thomson a24e656a 2021-09-04T10:16:41 common: support custom repository extensions Allow users to specify additional repository extensions that they want to support. For example, callers can specify that they support `preciousObjects` and then may open repositories that support `extensions.preciousObjects`. Similarly, callers may opt out of supporting extensions that the library itself supports.
Edward Thomson 3addb796 2021-08-30T23:10:24 Merge pull request #5943 from kcsaul/fix/5851 Fix worktree iteration when repository has no common directory
lhchavez 74708a81 2020-12-20T12:45:01 Homogenize semantics for atomic-related functions There were some subtle semantic differences between the various implementations of atomic functions. Now they behave the same, have tests and are better documented to avoid this from happening again in the future. Of note: * The semantics chosen for `git_atomic_compare_and_swap` match `InterlockedCompareExchangePointer`/`__sync_cal_compare_and_swap` now. * The semantics chosen for `git_atomic_add` match `InterlockedAdd`/`__atomic_add_fetch`. * `git_atomic_swap` and `git_atomic_load` still have a bit of semantic difference with the gcc builtins / msvc interlocked operations, since they require an l-value (not a pointer). If desired, this can be homogenized.
Kevin Saul e71505b3 2021-07-11T21:24:25 repo: fix worktree iteration when repo has no common directory When applying an operation to a repository created without a common directory, which is known to occur in scenarios where custom odb/refdb backends are used, git_repository_foreach_worktree currently asserts while attempting to open the repository located in the common directory. Fix this issue by applying operation to repository supplied when there are no linked worktrees to iterate (implied by common directory being empty).
Edward Thomson c44f5688 2021-05-02T10:27:56 Merge pull request #5823 from libgit2/ethomson/path_validation Working directory path validation
Edward Thomson c15ed350 2021-04-26T12:23:25 repo: validate repository paths Ensure that a repository's path (at initialization or open time) is valid. On Windows systems, this means that the longest known path beneath the repository will fit within MAX_PATH: this is a lock file for a loose object within the repository itself. Other paths, like a very long loose reference, may fail to be opened after the repository is opened. These variable length paths will be checked when they are accessed themselves. This new functionality is done at open to prevent needlessly checking every file in the gitdir (eg, `MERGE_HEAD`) for its length when we could instead check once at repository open time.
Edward Thomson 3589587d 2021-04-24T13:11:25 repo: factor the commondir detection
Edward Thomson e52c2989 2021-04-04T19:46:08 repository: validate workdir path lengths
Edward Thomson 50e01216 2021-03-20T16:39:29 repo: introduce git_repository_workdir_path Add a simple accessor for workdir paths to get an absolute on-disk path given a repository and a relative path within it. This is useful to avoid copy-pasta `git_buf_joinpath` and to ensure that we validate working directory paths while honoring `core.longpaths` settings.
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`.