Working trees support locking by creating a file `locked` inside
the tree's gitdir with an optional reason inside. Support this
feature by adding functions to get and set the locking status.
Add a new function that checks wether a given `struct
git_worktree` is valid. The validation includes checking if the
gitdir, parent directory and common directory are present.
Introduce a new `struct git_worktree`, which holds information
about a possible working tree connected to a repository.
Introduce functions to allow opening working trees for a
repository.
A repository's configuartion file can always be found in the
GIT_COMMON_DIR, which has been newly introduced. For normal
repositories this does change nothing, but for working trees this
change allows to access the shared configuration file.
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.
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.
The recent introduction of the commondir variable of a repository
requires callers to distinguish whether their files are part of
the dot-git directory or the common directory shared between
multpile worktrees. In order to take the burden from callers and
unify knowledge on which files reside where, the
`git_repository_item_path` function has been introduced which
encapsulate this knowledge.
Modify most existing callers of `git_repository_path` to use
`git_repository_item_path` instead, thus making them implicitly
aware of the common directory.
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.
Create worktrees for submodule repositories. The worktrees are
created for the parent repository (e.g. the one containing
submodules) and for the contained child repository.
As of recently, we failed to correctly discover repositories at a
Win32 system root. Instead of aborting the upwards-traversal of
the file system, we were looping infinitely when traversal
started at either a Win32 drive prefix ("C:/") or a network path
("//somehost").
The issue has been fixed, so add a test to catch regressions.
When calling `git_path_dirname_r` on a Win32 prefix, e.g. a drive
or network share prefix, we always want to return the trailing
'/'. This does not work currently when passing in a path like
'C:', where the '/' would not be appended correctly.
Fix this by appending a '/' if we try to normalize a Win32 prefix
and there is no trailing '/'.
Getting the dirname of a filesystem root should return the filesystem
root itself. E.g. the dirname of "/" is always "/". On Windows, we
emulate this behavior and as such, we should return e.g. "C:/" if
calling dirname on "C:/". But we currently fail to do so and instead
return ".", as we do not check if we actually have a Windows prefix
before stripping off the last directory component.
Fix this by calling out to `win32_prefix_length` immediately after
stripping trailing slashes, returning early if we have a prefix.
Extract code which determines if a path is at a Windows system's root.
This incluses drive prefixes (e.g. "C:\") as well as network computer
names (e.g. "//computername/").
The code reversing a vector initially determines the rear-pointer by
simply subtracting 1 from the vector's length. Obviously, this fails if
the vector is empty, in which case we have an integer overflow.
Fix the issue by returning early if the vector is empty.
Fix the following warning emitted by clang:
[ 16%] Building C object CMakeFiles/libgit2_clar.dir/src/submodule.c.o
/Users/mplough/devel/external/libgit2/src/submodule.c:408:6: warning: variable 'i' is used uninitialized whenever 'if' condition is true
[-Wsometimes-uninitialized]
if ((error = load_submodule_names(names, cfg)))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/mplough/devel/external/libgit2/src/submodule.c:448:20: note: uninitialized use occurs here
git_iterator_free(i);
^
/Users/mplough/devel/external/libgit2/src/submodule.c:408:2: note: remove the 'if' if its condition is always false
if ((error = load_submodule_names(names, cfg)))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/mplough/devel/external/libgit2/src/submodule.c:404:17: note: initialize the variable 'i' to silence this warning
git_iterator *i;
^
= NULL
1 warning generated.
