- 16 May, 2023 3 commits
-
-
PR #5712 predates several refactorings to move the utility code into a more general purpose codebase. Update to reflect the refactorings.
Edward Thomson committed -
Reginald McLean committed
-
Fixes #5598
Reginald McLean committed
-
- 31 Aug, 2022 1 commit
-
-
Miguel Arroz committed
-
- 23 Feb, 2022 1 commit
-
-
Edward Thomson committed
-
- 23 Dec, 2021 3 commits
-
-
Edward Thomson committed
-
Since we are able to give our own git checkout options, the default git checkout strategy will be the same as initialized in a new git_checkout_options struct.
punkymaniac committed -
Extend the `git_worktree_add_options` to include `git_checkout_options`. github issue #5949
punkymaniac committed
-
- 09 Nov, 2021 2 commits
-
-
Edward Thomson committed
-
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 committed
-
- 17 Oct, 2021 1 commit
-
-
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 committed
-
- 08 Aug, 2021 1 commit
-
-
Peter Pettersson committed
-
- 28 Apr, 2021 1 commit
-
-
Worktree paths need to fix within MAX_PATH always, regardless of `core.longpaths` setting.
Edward Thomson committed
-
- 27 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 21 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 06 Nov, 2020 1 commit
-
-
Fixes #5280
Reginald McLean committed
-
- 09 Jun, 2020 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 04 Apr, 2020 1 commit
-
-
Commit 0b5ba0d7 replaced this function with an "option_init" equivallent, but misspelled the replacement function. As a result, this symbol has been missing from libgit2.so ever since.
Seth Junot committed
-
- 07 Feb, 2020 1 commit
-
-
Git worktree's have the ability to be locked in order to spare them from deletion, e.g. if a worktree is absent due to being located on a removable disk it is a good idea to lock it. When locking such worktrees, it is possible to give a locking reason in order to help the user later on when inspecting status of any such locked trees. The function `git_worktree_is_locked` serves to read out the locking status. It currently does not properly report any errors when reading the reason file, and callers are unexpecting of any negative return values, too. Fix this by converting callers to expect error codes and checking the return code of `git_futils_readbuffer`.
Patrick Steinhardt committed
-
- 24 Jun, 2019 1 commit
-
-
Edward Thomson committed
-
- 23 Jun, 2019 1 commit
-
-
Use lowercase for our error messages, per our custom.
Edward Thomson committed
-
- 14 Jun, 2019 1 commit
-
-
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.
Edward Thomson committed
-
- 14 Feb, 2019 1 commit
-
-
When adding a new worktree, we only verify that an optionally given reference is valid half-way through the function. At this point, some data structures have already been created on-disk. If we bail out due to an invalid reference, these will be left behind and need to be manually cleaned up by the user. Improve the situation by moving the reference checks to the function's preamble. Like this, we error out as early as possible and will not leave behind any files.
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
-
- 16 Aug, 2018 1 commit
-
-
The documentation states that git_worktree_unlock returns 0 on success, and 1 on success if the worktree wasn't locked. Turns out we were returning 0 in any of those cases.
Etienne Samson committed
-
- 29 Jun, 2018 3 commits
-
-
Etienne Samson committed
-
Etienne Samson committed
-
Etienne Samson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 07 May, 2018 1 commit
-
-
Etienne Samson committed
-
- 25 Apr, 2018 1 commit
-
-
Matt Keeler committed
-
- 20 Apr, 2018 1 commit
-
-
Etienne Samson committed
-
- 03 Mar, 2018 1 commit
-
-
Jacques Germishuys committed
-
- 02 Mar, 2018 1 commit
-
-
Jacques Germishuys committed
-
- 09 Feb, 2018 1 commit
-
-
Currently, we always create a new branch after the new worktree's name when creating a worktree. In some workflows, though, the caller may want to check out an already existing reference instead of creating a new one, which is impossible to do right now. Add a new option `ref` to the options structure for adding worktrees. In case it is set, a branch and not already checked out by another worktree, we will re-use this reference instead of creating a new one.
Patrick Steinhardt 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 1 commit
-
-
Patrick Steinhardt committed
-
- 05 May, 2017 2 commits
-
-
The current signature of `git_worktree_prune` accepts a flags field to alter its behavior. This is not as flexible as we'd like it to be when we want to enable passing additional options in the future. As the function has not been part of any release yet, we are still free to alter its current signature. This commit does so by using our usual pattern of an options structure, which is easily extendable without breaking the API.
Patrick Steinhardt committed -
When creating a new worktree, we do have a potential race with us creating the worktree and another process trying to delete the same worktree as it is being created. As such, the upstream git project has introduced a flag `git worktree add --locked`, which will cause the newly created worktree to be locked immediately after its creation. This mitigates the race condition. We want to be able to mirror the same behavior. As such, a new flag `locked` is added to the options structure of `git_worktree_add` which allows the user to enable this behavior.
Patrick Steinhardt committed
-
- 02 May, 2017 1 commit
-
-
The `git_worktree_add` function currently accepts only a path and name for the new work tree. As we may want to expand these parameters in future versions without adding additional parameters to the function for every option, this commit introduces our typical pattern of an options struct. Right now, this structure is still empty, which will change with the next commit.
Patrick Steinhardt committed
-