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