kmx git

Commit	Date	Message
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).
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.
ce4cb073	2020-07-12T18:19:21	tests: verify renaming branch really updates worktree HEAD In case where a branch is getting renamed, all HEADs of the main repository and of its worktrees that point to the old branch need to get updated to point to the new branch. We already do so and have a test for this, but the test only verifies that we're able to lookup the updated HEAD, not what it contains. Let's make the test more specific by verifying the updated HEAD also has the correct updated symbolic target.
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.
ecf4f33a	2018-02-08T11:14:48	Convert usage of `git_buf_free` to new `git_buf_dispose`
fd7b5bc3	2018-04-20T12:54:41	Fix deletion of unrelated branch on worktree Signed-off-by: Sven Strickroth <email@cs-ware.de>
883eeb5f	2017-05-02T12:35:59	worktree: switch over worktree pruning to an opts structure 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.
2a485dab	2017-04-04T18:55:57	refs: update worktree HEADs when renaming branches Whenever we rename a branch, we update the repository's symbolic HEAD reference if it currently points to the branch that is to be renamed. But with the introduction of worktrees, we also have to iterate over all HEADs of linked worktrees to adjust them. Do so.
60297256	2017-04-04T16:12:27	tests: worktree::refs: convert spaces to tabs
097f0105	2017-03-17T08:54:53	refdb: create references in commondir 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.
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.
143e539f	2015-11-06T12:33:59	branch: restrict branch deletion for worktrees Restrict the ability to delete branches that are checked out in any linked repository.
e0a6c28e	2015-09-16T16:09:24	refdb: introduce commondir awareness 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.

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).

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.

ce4cb073

2020-07-12T18:19:21

tests: verify renaming branch really updates worktree HEAD In case where a branch is getting renamed, all HEADs of the main repository and of its worktrees that point to the old branch need to get updated to point to the new branch. We already do so and have a test for this, but the test only verifies that we're able to lookup the updated HEAD, not what it contains. Let's make the test more specific by verifying the updated HEAD also has the correct updated symbolic target.

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.

ecf4f33a

2018-02-08T11:14:48

Convert usage of `git_buf_free` to new `git_buf_dispose`

fd7b5bc3

2018-04-20T12:54:41

Fix deletion of unrelated branch on worktree Signed-off-by: Sven Strickroth <email@cs-ware.de>

883eeb5f

2017-05-02T12:35:59

worktree: switch over worktree pruning to an opts structure 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.

2a485dab

2017-04-04T18:55:57

refs: update worktree HEADs when renaming branches Whenever we rename a branch, we update the repository's symbolic HEAD reference if it currently points to the branch that is to be renamed. But with the introduction of worktrees, we also have to iterate over all HEADs of linked worktrees to adjust them. Do so.

60297256

2017-04-04T16:12:27

tests: worktree::refs: convert spaces to tabs

097f0105

2017-03-17T08:54:53

refdb: create references in commondir 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.

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.

143e539f

2015-11-06T12:33:59

branch: restrict branch deletion for worktrees Restrict the ability to delete branches that are checked out in any linked repository.

e0a6c28e

2015-09-16T16:09:24

refdb: introduce commondir awareness 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.

thodg/libgit2/tests/worktree/refs.c

tests/worktree/refs.c

Log