- 30 May, 2018 1 commit
-
-
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Sven Strickroth committed
-
- 29 May, 2018 1 commit
-
-
Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
Carlos Martín Nieto committed
-
- 30 Dec, 2017 1 commit
-
-
Perform some error checking when examining symlink directories.
Edward Thomson committed
-
- 29 Dec, 2017 1 commit
-
-
Native Git allows symlinked directories under .git/refs. This change allows libgit2 to also look for references that live under symlinked directories. Signed-off-by: Andy Doan <andy@opensourcefoundries.com>
Andy Doan committed
-
- 03 Jul, 2017 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 08 Jun, 2017 2 commits
-
-
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 -
Patrick Steinhardt committed
-
- 17 Mar, 2017 1 commit
-
-
References for a repository are usually created inside of its gitdir. When using worktrees, though, these references are not to be created inside the worktree gitdir, but instead inside the gitdir of its parent repository, which is the commondir. Like this, branches will still be available after the worktree itself has been deleted. The filesystem refdb currently still creates new references inside of the gitdir. Fix this and have it create references in commondir.
Patrick Steinhardt committed
-
- 06 Mar, 2017 1 commit
-
-
Edward Thomson committed
-
- 02 Mar, 2017 1 commit
-
-
Edward Thomson committed
-
- 28 Feb, 2017 3 commits
-
-
Rename `GIT_OPT_ENABLE_SYNCHRONIZED_OBJECT_CREATION` -> `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION`.
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
- 17 Feb, 2017 1 commit
-
-
Patrick Steinhardt committed
-
- 15 Feb, 2017 1 commit
-
-
The upstream git.git project currently identifies all references inside of `refs/bisect/` as well as `HEAD` as per-worktree references. This is already incorrect and is currently being fixed by an in-flight topic [1]. The new behavior will be to match all pseudo-references outside of the `refs/` hierarchy as well as `refs/bisect/`. Our current behavior is to mark a selection of pseudo-references as per-worktree, only. This matches more pseudo-references than current git, but forgets about `refs/bisect/`. Adjust behavior to match the in-flight topic, that is classify the following references as per-worktree: - everything outside of `refs/` - everything inside of `refs/bisect/` [1]: <20170213152011.12050-1-pclouds@gmail.com>
Patrick Steinhardt committed
-
- 13 Feb, 2017 4 commits
-
-
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 committed -
Patrick Steinhardt committed
-
The refdb_fs_backend is not aware of the git commondir, which stores common objects like the o bject database and packed/loose refereensces when worktrees are used. Make refdb_fs_backend aware of the common directory by introducing a new commonpath variable that points to the actual common path of the database and using it instead of the gitdir for the mentioned objects.
Patrick Steinhardt committed -
The variable '.path' of the refdb_fs_backend struct becomes confusing regarding the introduction of the git commondir. It does not immediatly become obvious what it should point to. Fix this problem by renaming the variable to `gitpath`, clarifying that it acutally points to the `.git` directory of the repository, in contrast to the commonpath directory, which points to the directory containing shared objects like references and the object store.
Patrick Steinhardt committed
-
- 29 Dec, 2016 1 commit
-
-
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
Edward Thomson committed
-
- 16 Dec, 2016 1 commit
-
-
Failure to bubble up this error means some locking errors do not get reported as such on Windows.
Carlos Martín Nieto committed
-
- 14 Nov, 2016 8 commits
-
-
Carlos Martín Nieto committed
-
On Windows we can find locked files even when reading a reference or the packed-refs file. Bubble up the error in this case as well to allow callers on Windows to retry more intelligently.
Carlos Martín Nieto committed -
It does not help us to check whether the file exists before trying to unlink it since it might be gone by the time unlink is called. Instead try to remove it and handle the resulting error if it did not exist.
Carlos Martín Nieto committed -
This allows the caller to know the errors was e.g. due to the packed-refs file being already locked and they can try again later.
Carlos Martín Nieto committed -
We can reduce the duplication by cleaning up at the beginning of the loop, since it's something we want to do every time we continue.
Carlos Martín Nieto committed -
There might be a few threads or processes working with references concurrently, so fortify the code to ignore errors which come from concurrent access which do not stop us from continuing the work. This includes ignoring an unlinking error. Either someone else removed it or we leave the file around. In the former case the job is done, and in the latter case, the ref is still in a valid state.
Carlos Martín Nieto committed -
In order not to undo concurrent modifications to references, we must make sure that we only delete a loose reference if it still has the same value as when we packed it. This means we need to lock it and then compare the value with the one we put in the packed file.
Carlos Martín Nieto committed -
We can get useful information like GIT_ELOCKED out of this instead of just -1.
Carlos Martín Nieto committed
-
- 11 Mar, 2016 1 commit
-
-
We usually check entries returned by `git_sortedcache_entry` for NULL pointers. As we have a write lock in `packed_write`, though, it really should not happen that the function returns NULL. Assert that ref is not NULL to silence a Coverity warning.
Patrick Steinhardt committed
-
- 23 Feb, 2016 1 commit
-
-
The fail-label of `reflog_parse` explicitly checks the entry poitner for NULL before freeing it. When we jump to the label the variable has to be set to a non-NULL and valid pointer though: if the allocation fails we immediately return with an error code and if the loop was not entered we return with a success code, withouth executing the label's code. Remove the useless NULL-check to silence Coverity.
Patrick Steinhardt committed
-
- 17 Feb, 2016 1 commit
-
-
Allow `git_index_read` to handle reading existing indexes with illegal entries. Allow the low-level `git_index_add` to add properly formed `git_index_entry`s even if they contain paths that would be illegal for the current filesystem (eg, `AUX`). Continue to disallow `git_index_add_bypath` from adding entries that are illegal universally illegal (eg, `.git`, `foo/../bar`).
Edward Thomson committed
-
- 12 Nov, 2015 2 commits
-
-
When a non-empty directory exists and prevents the creation of a reflog, provide a more informative error message.
Edward Thomson committed -
When a (non-empty) directory exists at the reference target location, complain with a more actionable error message.
Edward Thomson committed
-
- 29 Oct, 2015 1 commit
-
-
Using calloc instead of malloc because the parse error will lead to an immediate free of committer (and its properties, which can segfault on free if undefined - test_refs_reflog_reflog__reading_a_reflog_with_invalid_format_returns_error segfaulted before the fix). #3458
Stjepan Rajko committed
-
- 28 Oct, 2015 1 commit
-
-
Vicent Marti committed
-
- 17 Sep, 2015 1 commit
-
-
Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter assumes that we own everything beneath the base, as if it were being called with a base of the repository or working directory, and is tailored towards checkout and ensuring that there is no bogosity beneath the base that must be cleaned up. This is (at best) slow and (at worst) unsafe in the larger context of a filesystem where we do not own things and cannot do things like unlink symlinks that are in our way.
Edward Thomson committed
-
- 28 Aug, 2015 1 commit
-
-
Edward Thomson committed
-
- 12 Jul, 2015 1 commit
-
-
Removing a reflog upon ref deletion is something which only some backends might wish to do. Backends which are database-backed may wish to archive a reflog, log-based ones may not need to do anything.
Carlos Martín Nieto committed
-
- 08 Mar, 2015 1 commit
-
-
When we rename a reference, we want the old and new ids to be the same one (as we did not change it). The normal code path looks up the old id from the current value of the brtanch, but by the time we look it up, it does not exist anymore and thus we write a zero id. Pass the old id explicitly instead.
Carlos Martín Nieto committed
-