|
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.
|
|
|
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.
|
|
|
4f24a932
|
2021-09-14T07:45:50
|
|
Merge pull request #6031 from libgit2/ethomson/extensions
Support custom git extensions
|
|
379c4646
|
2021-09-09T19:49:04
|
|
Fix coding style for pointer
Make some syntax change to follow coding style.
|
|
|
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.
|
|
|
3addb796
|
2021-08-30T23:10:24
|
|
Merge pull request #5943 from kcsaul/fix/5851
Fix worktree iteration when repository has no common directory
|
|
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.
|
|
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).
|
|
|
c44f5688
|
2021-05-02T10:27:56
|
|
Merge pull request #5823 from libgit2/ethomson/path_validation
Working directory path validation
|
|
|
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.
|
|
|
3589587d
|
2021-04-24T13:11:25
|
|
repo: factor the commondir detection
|
|
|
e52c2989
|
2021-04-04T19:46:08
|
|
repository: validate workdir path lengths
|
|
|
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.
|
|
|
ac77d306
|
2021-04-13T17:00:37
|
|
Merge pull request #5834 from libgit2/cmn/repo-no-passthrough
repo: remove an inappropriate use of PASSTHROUGH
|
|
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.
|
|
|
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.
|
|
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
|
|
|
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/`.
|
|
|
1ab2f577
|
2020-12-11T05:13:16
|
|
Fix an oops
|
|
|
6cd0c853
|
2020-12-11T05:08:45
|
|
Small refactor to make thing tidier
Also repurposed an unused function and deleted another one.
|
|
|
ab772974
|
2020-12-05T15:49:30
|
|
threads: give atomic functions the git_atomic prefix
|
|
|
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
|
|
|
36adde56
|
2020-04-05T21:17:42
|
|
repository: use GIT_ASSERT
|
|
|
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.
|
|
|
b52bb4d4
|
2020-10-11T13:20:52
|
|
refs: use git_reference_name_is_valid
|
|
5b7e7131
|
2020-10-07T15:54:08
|
|
Fix error return for invalid extensions.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
dfd7fcc4
|
2020-04-02T13:26:13
|
|
Merge pull request #5388 from bk2204/repo-format-v1
Handle repository format v1
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
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>
|
|
|
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.
|
|
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.
|
|
dde6d9c7
|
2019-09-10T17:09:57
|
|
open:move all cleanup code to cleanup label in git_repository_open_ext
|
|
|
b545be3d
|
2019-09-10T11:14:36
|
|
open:fix memory leak when passing NULL to git_repository_open_ext
|
|
|
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.
|
|
|
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.
|
|
|
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
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
658022c4
|
2019-07-18T13:53:41
|
|
configuration: cvar -> configmap
`cvar` is an unhelpful name. Refactor its usage to `configmap` for more
clarity.
|
|
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`.
|
|
|
fc3a94ba
|
2019-05-20T07:13:42
|
|
repository: use size_t for length
|
|
|
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.
|
|
9cc904da
|
2019-05-23T10:49:44
|
|
repository: fix garbage return value
error was never initialized and a garbage value returned on success.
|
|
|
4069f924
|
2019-02-22T10:56:08
|
|
Merge pull request #4901 from pks-t/pks/uniform-map-api
High-level map APIs
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
b8b796c1
|
2019-01-20T18:09:43
|
|
repository: free memory in symlink detection function
|
|
|
ed8cfbf0
|
2019-01-17T00:32:31
|
|
references: use new names in internal usage
Update internal usage to use the `git_reference` names for constants.
|
|
|
168fe39b
|
2018-11-28T14:26:57
|
|
object_type: use new enumeration names
Use the new object_type enumeration names within the codebase.
|
|
|
18e71e6d
|
2018-11-28T13:31:06
|
|
index: use new enum and structure names
Use the new-style index names throughout our own codebase.
|
|
|
0ddc6094
|
2018-11-30T09:46:14
|
|
Merge pull request #4770 from tiennou/feature/merge-analysis-any-branch
Allow merge analysis against any reference
|
|
|
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>
|
|
|
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.
|
|
|
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.
|
|
|
5c0c8fdd
|
2018-08-17T02:07:38
|
|
repository: assert that we're passed a valid head pointer
|
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
|
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
|
|
|
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.
|
|
|
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`.
|
|
|
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.
|
|
|
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.
|
|
af720bb6
|
2017-06-16T23:19:31
|
|
repository: remove trailing whitespace
|
|
|
9a46c777
|
2017-06-16T21:02:26
|
|
repository: do not initialize templates if dir is an empty string
|
|
|
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.
|
|
|
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.
|
|
|
fb3fc837
|
2017-06-12T11:45:09
|
|
repository_item_path: error messages lowercased
|
|
|
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.
|
|
|
04de614b
|
2017-06-04T19:03:07
|
|
Merge pull request #4243 from pks-t/pks/submodule-workdir
Submodule working directory
|
|
|
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
|
|
|
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.
|
|
|
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.
|
|
|
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`
|
|
|
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.
|
|
|
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`.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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`.
|
|
|
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`.
|
|
1c04a96b
|
2017-02-28T12:29:29
|
|
Honor `core.fsyncObjectFiles`
|
|
|
13c3bc9a
|
2017-01-27T14:32:23
|
|
strmap: remove GIT__USE_STRMAP macro
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|