- 18 Oct, 2019 2 commits
-
-
In previous versions, libgit2 could be coerced into writing reflog messages with embedded newlines into the reflog by using `git_stash_save` with a message containing newlines. While the root cause is fixed now, it was noticed that upstream git is in fact able to read such corrupted reflog messages just fine. Make the reflog parser more lenient in order to just skip over malformatted reflog lines to bring us in line with git. This requires us to change an existing test that verified that we do indeed _fail_ to parse such logs.
Patrick Steinhardt committed -
Currently, the reflog disallows any entries that have a message with newlines, as that would effectively break the reflog format, which may contain a single line per entry, only. Upstream git behaves a bit differently, though, especially when considering stashes: instead of rejecting any reflog entry with newlines, git will simply replace newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will create a reflog entry with "foo bar" as entry message. This commit adjusts our own logic to stop rejecting commit messages with newlines. Previously, this logic was part of `git_reflog_append`, only. There is a second place though where we add reflog entries, which is the serialization code in the filesystem refdb. As it didn't contain any sanity checks whatsoever, the refdb would have been perfectly happy to write malformatted reflog entries to the disk. This is being fixed with the same logic as for the reflog itself.
Patrick Steinhardt committed
-
- 17 Oct, 2019 1 commit
-
-
Refs which are locked in a transaction without an altered target, still should to be unlocked on `git_transaction_commit`. `git_transaction_free` also unlocks refs but the moment of calling of `git_transaction_free` cannot be controlled in all situations. Some binding libs call `git_transaction_free` on garbage collection or not at all if the application exits before and don't provide public access to `git_transaction_free`. It is better to release locks as soon as possible.
Sebastian Henke committed
-
- 10 Oct, 2019 1 commit
-
-
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.
Sebastian Henke committed
-
- 21 Aug, 2019 1 commit
-
-
The code worked under the assumption that anything under `refs/tags` are tag objects, and all the rest would be peelable to a commit. As it is completely valid to have tags to blobs under a non `refs/tags` ref, this would cause failures when trying to peel a tag to a commit. Fix the broken filtering by switching to `git_revwalk_push_glob`, which already handles this case.
Etienne Samson committed
-
- 20 Jul, 2019 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 26 Apr, 2019 1 commit
-
-
In commit cd377f45c9 (refs: loosen restriction on wildcard "*" refspecs, 2015-07-22) in git.git, the restrictions on wildcard "*" refspecs has been loosened. While wildcards were previously only allowed if the component is a single "*", this was changed to also accept other patterns as part of the component. We never adapted to that change and still reject any wildcard patterns that aren't a single "*" only. Update our tests to reflect the upstream change and adjust our own code accordingly.
Patrick Steinhardt committed
-
- 22 Feb, 2019 1 commit
-
-
Augustin Fabre committed
-
- 14 Feb, 2019 3 commits
-
-
In a bare repository, HEAD usually points to the branch that is considered the "default" branch. As the current implementation for `git_branch_is_checked_out` only does a comparison of HEAD with the branch that is to be checked, it will say that the branch pointed to by HEAD in such a bare repo is checked out. Fix this by skipping the main repo's HEAD when it is bare.
Patrick Steinhardt committed -
Libraries should use assert(3P) only very scarcely. First, we usually shouldn't cause the caller of our library to abort in case where the assert fails. Second, if code is compiled with -DNDEBUG, then the assert will not be included at all. In our `git_branch_is_checked_out` function, we have an assert that verifies that the given reference parameter is non-NULL and in fact a branch. While the first check is fine, the second is not. E.g. when compiled with -DNDEBUG, we'd proceed and treat the given reference as a branch in all cases. Fix the issue by instead treating a non-branch reference as not being checked out. This is the obvious solution, as references other than branches cannot be directly checked out.
Patrick Steinhardt committed -
We currently do not have any tests at all for the `git_branch_is_checked_out` function. Add some basic ones.
Patrick Steinhardt committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 17 Jan, 2019 1 commit
-
-
Update internal usage to use the `git_reference` names for constants.
Edward Thomson committed
-
- 01 Dec, 2018 1 commit
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed
-
- 18 Nov, 2018 1 commit
-
-
Since we were not expecting this config entry to contain a string, we would fail as soon as its (cached) value would be accessed. Hence, provide some constants for the 4 states we use, and account for "always" when we decide to reflog changes.
Etienne Samson committed
-
- 13 Oct, 2018 1 commit
-
-
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Sven Strickroth committed
-
- 13 Jul, 2018 1 commit
-
-
C++ style comment ("//") are not specified by the ISO C90 standard and thus do not conform to it. While libgit2 aims to conform to C90, we did not enforce it until now, which is why quite a lot of these non-conforming comments have snuck into our codebase. Do a tree-wide conversion of all C++ style comments to the supported C style comments to allow us enforcing strict C90 compliance in a later commit.
Patrick Steinhardt committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 01 Jun, 2018 1 commit
-
-
Julian Ganz committed
-
- 04 May, 2018 1 commit
-
-
Since version 8.1, GCC will do some automatic bounds checking when printing static content into a buffer with known size. The bounds checking doesn't yet work quite right in all scenarios and may thus lead to false positives. Fix one of these false positives in refs::normalize by simplifying the code.
Patrick Steinhardt committed
-
- 10 Apr, 2018 1 commit
-
-
This fixes a segfault in git_reference_owner on references returned from git_reference__read_head and git_reference_dup ones.
Etienne Samson committed
-
- 24 Feb, 2018 1 commit
-
-
Add a new branch to the `testrepo` repository, where the `README` file has changed to executable. This branch enables typechange tests between the new `executable` branch and `master`.
Edward Thomson committed
-
- 12 Jan, 2018 1 commit
-
-
The test refs::iterator::foreach_name iterates through every reference and copies its name into a local vector. While the test makes sure to free the vector afterwards, the copied reference names are not being free'd. Fix that.
Patrick Steinhardt committed
-
- 30 Dec, 2017 1 commit
-
-
Ensure that we can recurse into directories via symbolic links.
Edward Thomson committed
-
- 22 Nov, 2017 1 commit
-
-
Etienne Samson committed
-
- 14 Nov, 2017 4 commits
-
-
Etienne Samson committed
-
Etienne Samson committed
-
Etienne Samson committed
-
Etienne Samson committed
-
- 06 Oct, 2017 1 commit
-
-
If a reference stored in a packed-refs file does not directly point to a commit, tree or blob, the packed-refs file will also will include a fully-peeled OID pointing to the first underlying object of that type. If we try to peel a reference to an object, we will use that peeled OID to speed up resolving the object. As a reference for an annotated tag does not directly point to a commit, tree or blob but instead to the tag object, the packed-refs file will have an accomodating fully-peeled OID pointing to the object referenced by that tag. When we use the fully-peeled OID pointing to the referenced object when peeling, we obviously cannot peel that to the tag anymore. Fix this issue by not using the fully-peeled OID whenever we want to peel to a tag. Note that this does not include the case where we want to resolve to _any_ object type. Existing code may make use from the fact that we resolve those to commit objects instead of tag objects, even though that behaviour is inconsistent between packed and loose references. Furthermore, some tests of ours make the assumption that we in fact resolve those references to a commit.
Patrick Steinhardt committed
-
- 23 Jun, 2017 1 commit
-
-
The test `refs::crashes::double_free` operates on our in-source "testrepo.git" repository without creating a copy first. As the test will try to create a new symbolic reference, this will fail when we want to do a pure out-of-tree build with a read-only source tree. Fix the issue by creating a sandbox first.
Patrick Steinhardt committed
-
- 08 Jun, 2017 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 05 May, 2017 1 commit
-
-
Support '..' and '...' ranges where one side is not specified. The unspecified side defaults to HEAD. Closes #4223
William Bain committed
-
- 06 Mar, 2017 1 commit
-
-
These simple tests only ensure that we enforce the existence of a namespace; these mirror the rugged tests, they are not exhaustive.
Edward Thomson committed
-
- 02 Mar, 2017 1 commit
-
-
Edward Thomson committed
-
- 01 Mar, 2017 1 commit
-
-
Patrick Steinhardt committed
-
- 28 Feb, 2017 4 commits
-
-
This test ensures that the string '(merge)' is included in the reflog when a merge commit is made.
Richard Ipsum committed -
Windows doesn't support it.
Edward Thomson committed -
Rename `GIT_OPT_ENABLE_SYNCHRONIZED_OBJECT_CREATION` -> `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION`.
Edward Thomson committed -
When fsync'ing files, fsync the parent directory in the case where we rename a file into place, or create a new file, to ensure that the directory entry is flushed correctly.
Edward Thomson committed
-