|
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.
|
|
d0921127
|
2018-06-29T14:39:13
|
|
tests: add a helper to build sandbox subpaths quickly
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
|
3017ba94
|
2017-03-15T14:24:25
|
|
worktree: implement `git_worktree_open_from_repository`
While we already provide functionality to look up a worktree from a
repository, we cannot do so the other way round. That is given a
repository, we want to look up its worktree if it actually exists.
Getting the worktree of a repository is useful when we want to get
certain meta information like the parent's location, getting the locked
status, etc.
|
|
|
fdb3e24a
|
2017-03-15T14:23:59
|
|
tests: worktree: unify init/cleanup in open tests
|
|
|
aa593a65
|
2017-03-15T12:01:02
|
|
tests: worktree: move submodule tests into own suite
|
|
|
3f3a4ce7
|
2016-11-09T14:18:22
|
|
worktree: test opening worktree via gitlink, gitdir and worktree
|
|
|
1fd6e035
|
2016-11-07T10:23:34
|
|
worktree: test opening discovered submodule worktrees
|
|
|
39abd3ad
|
2016-11-04T13:39:54
|
|
worktree: compute workdir for worktrees opened via their gitdir
When opening a worktree via the gitdir of its parent repository
we fail to correctly set up the worktree's working directory. The
problem here is two-fold: we first fail to see that the gitdir
actually is a gitdir of a working tree and then subsequently
fail to determine the working tree location from the gitdir.
The first problem of not noticing a gitdir belongs to a worktree
can be solved by checking for the existence of a `gitdir` file in
the gitdir. This file points back to the gitlink file located in
the working tree's working directory. As this file only exists
for worktrees, it should be sufficient indication of the gitdir
belonging to a worktree.
The second problem, that is determining the location of the
worktree's working directory, can then be solved by reading the
`gitdir` file in the working directory's gitdir. When we now
resolve relative paths and strip the final `.git` component, we
have the actual worktree's working directory location.
|
|
|
79ab3ef6
|
2015-10-15T15:58:05
|
|
repository: introduce is_worktree variable
|
|
|
c09fd54e
|
2015-09-16T12:10:11
|
|
repository: introduce commondir variable
The commondir variable stores the path to the common directory.
The common directory is used to store objects and references
shared across multiple repositories. A current use case is the
newly introduced `git worktree` feature, which sets up a separate
working copy, where the backing git object store and references
are pointed to by the common directory.
|