thodg/libgit2/src/refdb_fs.c

---

src/refdb_fs.c

---

Log

Author	Commit	Date	CI	Message
	0a72a3ad	2022-01-13T17:43:30		Fix compiler warning on Windows.
	ac07a40a	2022-01-12T16:57:51		Check packed-refs filestamp before reusing mmap. Avoid using a stale mmap() by tracking the filestamp.
	cdf05a1d	2022-01-12T16:28:45		On windows, copy file into memory instead of mmap. Since mmap() on windows locks the file, and this map is long-lived, just copy the file into memory instead. This enables us to keep the lookup() paths the same, while avoiding the downsides of mmap() on windows.
	60faa631	2022-01-13T17:32:48		Drop redundant check in packed_set_peeling_mode(). Co-authored-by: Edward Thomson <ethomson@github.com>
	d86b9f79	2022-01-13T17:23:01		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	678c9ddf	2022-01-13T17:22:13		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	b162bb35	2022-01-13T17:20:53		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	c55275ff	2022-01-13T17:20:47		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	620e3abc	2022-01-13T17:20:27		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	99fc3d49	2022-01-13T17:20:20		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	c6c6c0bd	2022-01-13T17:20:14		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	d89f1fe5	2022-01-13T17:20:09		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	a0381cf2	2022-01-13T17:20:04		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	10abd7bc	2022-01-13T17:19:57		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	207840d8	2021-12-24T10:48:02		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	2ec7b291	2021-12-24T10:47:53		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	2b722da4	2021-12-24T10:47:43		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	0df53fd6	2021-12-24T10:47:32		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	3f52f7b9	2021-12-24T10:47:22		Update src/refdb_fs.c Co-authored-by: Edward Thomson <ethomson@github.com>
	ad7a51d8	2021-10-07T13:26:52		refs: Speed up packed lookups. Currently ref lookups require loading the entire packed-refs file into a hashmap in memory. For repos with large numbers of refs this can be painfully slow. This patch replaces the existing lookup code and instead mmap()'s the packed-refs file and performs a binary search to locate the ref entry. Git uses a similiar approach. The old hash table codepath is still used for unsorted packed-refs files. This patch also fixes a minor bug where the "peeled" trait is never parsed correctly from the packed-refs header.
	7dcc29fc	2021-10-22T22:51:59		Make enum in src,tests and examples C90 compliant by removing trailing comma.
	62251409	2021-11-01T21:09:17		fs_path: add length with suffix validation
	91246ee5	2021-11-01T20:14:34		path: use new length validation functions
	63e36c53	2021-11-01T09:34:32		path: `validate` -> `is_valid` Since we're returning a boolean about validation, the name is more properly "is valid".
	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.
	379c4646	2021-09-09T19:49:04		Fix coding style for pointer Make some syntax change to follow coding style.
	efc4e7e5	2021-08-25T12:30:06		Merge pull request #5802 from lhchavez/git-warn-unused-result Introduce GIT_WARN_UNUSED_RESULT
	231ca4fa	2021-02-23T19:33:34		Proof-of-concept for a more aggressive GIT_UNUSED() This adds a `-Wunused-result`-proof `GIT_UNUSED()`, just to demonstrate that it works. With this, sortedcache.h is now completely `GIT_WARN_UNUSED_RESULT`-annotated!
	4584660e	2021-08-08T12:13:16		bugfix: don't generate paths with empty segments
	58944388	2021-05-16T11:11:56		Merge branch 'zero_oid_in_old' Manually merging #5842
	e5851c62	2021-04-24T09:44:45		refs: ensure loose refs adhere to path validation On Windows, we need to enforce MAX_PATH for loose references and their reflogs. Ensure that any path - including the lock file - would fit within the 260 character maximum. We do not honor core.longpaths for loose reference files or reflogs. core.longpaths only applies to paths in the working directory.
	95b7a639	2021-04-14T21:52:36		git_reference_create_matching: Treat all-zero OID as "must be absent" This is pretty useful in avoiding races: I want to create a ref only if it doesn't already exist. I can't check first because of TOCTOU -- by the time I finish the check, someone else might have already created the ref. And I can't take a lock because then I can't do the create, since the create expects to take the lock. The semantics are inspired by git update-ref, which allows an all-zero old value to mean that the ref must not exist.
	88323cd0	2021-03-20T09:52:17		path: git_path_isvalid -> git_path_validate If we want to validate more and different types of paths, the name `git_path_validate` makes that easier and more expressive. We can add, for example, `git_path_validate_foo` while the current name makes that less ergonomic.
	36232528	2021-02-16T13:08:02		refdb_fs: Check git_sortedcache wlock/rlock errors To prevent a race condition, these wlock/rlock calls should probably be checked for errors.
	98a4f278	2020-04-05T21:38:42		refdb_fs: use GIT_ASSERT
	1f39593b	2020-06-30T08:53:59		refdb: extract function to check whether to append HEAD to the reflog The logic to determine whether a reflog entry should be for the HEAD reference is non-trivial. Currently, the only user of this is the filesystem-based refdb, but with the advent of the reftable refdb we're going to add a second user that's interested in having the same behaviour. Let's pull out a new function that checks whether a given reference should cause a entry to be written to the HEAD reflog as a preparatory step.
	e02478b1	2020-06-05T08:17:03		refdb: extract function to check whether a reflog should be written The logic to determine whether a reflog should be written is non-trivial. Currently, the only user of this is the filesystem-based refdb, but with the advent of the reftable refdb we're going to add a second user that's interested in having the same behaviour. Let's pull out a new function that checks whether a given reference should cause a reflog to be written as a preparatory step.
	0f35efeb	2020-05-23T10:15:51		git_pool_init: handle failure cases Propagate failures caused by pool initialization errors.
	74e0489a	2020-03-24T19:42:10		refdb_fs: remove unused header file The "refdb_fs.h" header contains a single struct `git_refcache` that is not used anywhere. As a result, we can just delete the header altogether as it doesn't have any purpose and may confuse readers.
	a2d3316a	2020-03-13T23:01:11		refdb_fs: initialize backend version While the `git_refdb_backend()` struct has a version, we do not initialize it correctly when calling `git_refdb_backend_fs()`. Fix this by adding the call to `git_refdb_init_backend()`.
	97b8491b	2019-12-08T15:25:52		refs: rename git_reference__set_name to git_reference__realloc As git_reference__name will reallocate storage to account for longer names (it's actually allocator-dependent), it will cause all existing pointers to the old object to become dangling, as they now point to freed memory. Fix the issue by renaming to a more descriptive name, and pass a pointer to the actual reference that can safely be invalidated if the realloc succeeds.
	7968e90f	2019-10-18T12:33:07		refdb_fs: properly parse corrupted reflogs In previous versions, libgit2 could be coerced into writing reflog messages with embedded newlines into the reflog by using `git_stash_save` with a message containing newlines. While the root cause is fixed now, it was noticed that upstream git is in fact able to read such corrupted reflog messages just fine. Make the reflog parser more lenient in order to just skip over malformatted reflog lines to bring us in line with git. This requires us to change an existing test that verified that we do indeed _fail_ to parse such logs.
	8532ed11	2019-10-18T12:14:19		refdb_fs: convert reflog parsing to use parser The refdb_fs code to parse the reflog currently uses a hand-rolled parser. Convert it to use our `git_parse_ctx` structure instead.
	d8233feb	2019-10-18T09:24:14		reflog: allow adding entries with newlines in their message Currently, the reflog disallows any entries that have a message with newlines, as that would effectively break the reflog format, which may contain a single line per entry, only. Upstream git behaves a bit differently, though, especially when considering stashes: instead of rejecting any reflog entry with newlines, git will simply replace newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will create a reflog entry with "foo bar" as entry message. This commit adjusts our own logic to stop rejecting commit messages with newlines. Previously, this logic was part of `git_reflog_append`, only. There is a second place though where we add reflog entries, which is the serialization code in the filesystem refdb. As it didn't contain any sanity checks whatsoever, the refdb would have been perfectly happy to write malformatted reflog entries to the disk. This is being fixed with the same logic as for the reflog itself.
	3335a034	2019-10-10T15:28:46		refs: fix locks getting forcibly removed The flag GIT_FILEBUF_FORCE currently does two things: 1. It will cause the filebuf to create non-existing leading directories for the file that is about to be written. 2. It will forcibly remove any pre-existing locks. While most call sites actually do want (1), they do not want to remove pre-existing locks, as that renders the locking mechanisms effectively useless. Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to separate both behaviours cleanly from each other and convert callers to use it instead of `GIT_FILEBUF_FORCE` to have them honor locked files correctly. As this conversion removes all current users of `GIT_FILEBUF_FORCE`, this commit removes the flag altogether.
	8c142241	2019-06-14T08:20:05		refdb: make sure to remove packed refs first This fixes part of the issue where, given a concurrent `git pack-refs`, a ref lookup could return an old, vestigial value from the packed file, as the valid loose one would have been deleted.
	171116e7	2019-06-14T06:50:41		refdb: repurpose filesystem prune function
	8fd855fd	2019-02-02T19:00:51		refdb: reorder parameters for consistency
	9b25cf15	2019-02-02T19:00:49		refdb: fix packed_delete clobbering some errors In the case of a failed lookup, we'd paper over that by writing back the packed-refs successfully.
	0a88c83d	2019-02-02T19:00:47		refdb: make low-level deletion helpers explicit
	8db9fd3b	2019-02-02T19:00:41		refdb: documentation
	e54343a4	2019-06-29T09:17:32		fileops: rename to "futils.h" to match function signatures Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
	658022c4	2019-07-18T13:53:41		configuration: cvar -> configmap `cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
	451df793	2019-06-13T15:20:23		posix: remove implicit include of "fnmatch.h" We're about to phase out our bundled fnmatch implementation as git.git has moved to wildmatch long ago in 2014. To make it easier to spot which files are stilll using fnmatch, remove the implicit "fnmatch.h" include in "posix.h" and instead include it explicitly.
	de70bb46	2019-06-13T15:27:22		global: convert trivial `fnmatch` users to use `wildcard` Upstream git.git has converted its codebase to use wildcard in favor of fnmatch in commit 70a8fc999d (stop using fnmatch (either native or compat), 2014-02-15). To keep our own regex-matching in line with what git does, convert all trivial instances of `fnmatch` usage to use `wildcard`, instead. Trivial usage is defined to be use of `fnmatch` with either no flags or flags that have a 1:1 equivalent in wildmatch (PATHNAME, IGNORECASE).
	2e246474	2019-04-16T13:19:53		refdb_fs: make use of the `GIT_CONTAINER_OF` macro
	94743daf	2019-02-15T11:16:46		refdb_fs: fix race when migrating loose to packed refs in iteration Right now, we first load the packed refs cache and only afterwards load the loose references. This is susceptible to a race when the loose ref is being migrated to a packed cache by e.g. git-pack-refs(1): libgit2 git-pack-refs 1. We load the packed ref, which does not yet have the migrated reference. 2. git-pack-refs updates the packed ref file to have the migrated ref. 3. git-pack-refs deletes the old loose ref. 4. We look up the loose ref. So we now do not find the reference at all and will never iterate over it. Fix the issue by reversing the order: instead of first loading the packed refs, we will now look up the loose reference first. If it has already been deleted, then it must already be present in the packed-refs by definition, as git.git will only delete the reference after updating the packed refs file.
	3ff0e3b5	2019-02-15T11:16:05		refdb_fs: remove ordering dependency on loose/packed refs loading Right now, loading loose refs has the side-effect of setting the `PACKREF_SHADOWED` flag for references that exist both in the loose and the packed refs. Because of this, we are force do first look up packed refs and only afterwards loading the packed refs. This is susceptible to a race, though, when refs are being repacked: when first loading the packed cache, then it may not yet have the migrated loose ref. But when now trying to look up the loose reference afterwards, then it may already have been migrated. Thus, we would fail to find this reference in this scenario. Remove this ordering dependency to allow fixing the above race. Instead of setting the flag when loading loose refs, we will now instead set it lazily when iterating over the loose refs. This even has the added benefit of not requiring us to lock the packed refs cache, as we already have an owned copy of it.
	83333814	2019-02-15T10:56:50		refdb_fs: do not lazily copy packed ref cache When creating a new iterator, we eagerly load loose refs but only lazily create a copy of packed refs. The lazy load only happens as soon as we have iterated over all loose refs, opening up a potentially wide window for races. This may lead to an inconsistent view e.g. when the caller decides to reload packed references somewhen between iterating the loose refs, which is unexpected. Fix the issue by eagerly copying the sorted cache. Note that right now, we are heavily dependent on ordering here: we first need to reload packed refs, then we have to load loose refs and only as a last step are we allowed to copy the cache. This is because loading loose refs has the side-effect of setting the `PACKED_SHADOWED` flag in the packed refs cache, which we require to avoid outputting packed refs that already exist as loose refs.
	32063d82	2019-02-15T10:41:30		refdb_fs: refactor error handling in iterator creation Refactor the error handling in `refdb_fs_backend__iterator` to always return the correct error code returned by the failing function.
	8c773438	2019-02-15T10:15:39		refdb_fs: fix potential race with ref repacking in `exists` callback When repacking references, git.git will first update the packed refs and only afterwards delete any existing loose references that have now been moved to the new packed refs file. Due to this, there is a potential for racing if one first reads the packfile (which has not been updated yet) and only then trying to read the loose reference (which has just been deleted). In this case, one will incorrectly fail to lookup the reference and it will be reported as missing. Naturally, this is exactly what we've been doing in `refdb_fs_backend__exists`. Fix the race by reversing the lookup: we will now first check if the loose reference exists and only afterwards refresh the packed file.
	f673e232	2018-12-27T13:47:34		git_error: use new names in internal APIs and usage Move to the `git_error` name in the internal API for error-related functions.
	ed8cfbf0	2019-01-17T00:32:31		references: use new names in internal usage Update internal usage to use the `git_reference` names for constants.
	8dde7e11	2018-12-19T11:04:58		refdb_fs: refactor error handling in `refdb_reflog_fs__delete` The function `refdb_reflog_fs__delete` uses the `if (!error && foobar())` pattern of checking, where error conditions are being checked by following calls to different code. This does not match our current style, where the call-site of a function is usually directly responsible for checking the return value. Convert the function to use `if ((error = foobar()) < 0) goto out;` style. Note that this changes the code flow a bit: previously, we were always trying to delete empty reference hierarchies even if deleting the reflog entry has failed. This wasn't much of a problem -- if deletion failed, the hierarchy will still contain at least one file and thus the function call was an expensive no-op. Now, we will only perform this deletion if we have successfully removed the reflog.
	bc219657	2018-12-19T11:01:55		Merge pull request #4833 from csware/drop-empty-dirs Remove empty (sub-)directories when deleting refs
	168fe39b	2018-11-28T14:26:57		object_type: use new enumeration names Use the new object_type enumeration names within the codebase.
	e226ad8f	2018-11-17T17:55:10		refs: add support for core.logAllRefUpdates=always Since we were not expecting this config entry to contain a string, we would fail as soon as its (cached) value would be accessed. Hence, provide some constants for the 4 states we use, and account for "always" when we decide to reflog changes.
	9f48dc3b	2018-10-05T12:47:32		Remove empty directories when deleting refs Signed-off-by: Sven Strickroth <email@cs-ware.de>
	ecf4f33a	2018-02-08T11:14:48		Convert usage of `git_buf_free` to new `git_buf_dispose`
	05e891f1	2018-06-01T08:44:30		refdb_fs: test whether the base directory exists when globbing This commit fixes a regression introduced by 20a2b02d9a1bcb4825ec49605146223c565dcacf The commit introduced an optimization for finding references using a glob: rather than iterating over all references and matching each one against the glob, we would iterate only over references within the directory common to all possible references which may match against the glob. However, contrary to the `ref/` directory, which was the previous entry point for the iteration, this directory may not exist. In this case, the optimization causes an error (`ENOENT`) rather than the iterator simply yielding no references. This patch fixes the regression by checkign for this specific case.
	7f6c1ce9	2018-05-29T21:04:39		Merge pull request #4660 from libgit2/cmn/submodule-traversal Fixes for CVE 2018-11235
	a7168b47	2018-05-22T16:13:47		path: reject .gitmodules as a symlink Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
	0a19c151	2018-05-09T14:14:06		Merge pull request #4629 from neithernut/enhance-glob-perf refdb_fs: enhance performance of globbing
	20a2b02d	2018-04-18T19:23:40		refdb_fs: enable root arbitration for fixed portion of globs A glob used for iteration may start with an entire path containing no special characters. If we start scanning for references within that path rather than in `refs/`, we may end up scanning only a small fraction of all references.
	27e98cf7	2018-04-18T19:21:22		refdb_fs: prepare arbitration of the root used for ref iteration Instead of a hardcoded "refs", we may choose a different directory within the git directory as the root from which we look for references.
	5ace1494	2018-04-26T11:45:38		Merge pull request #4633 from csware/worktree-delereref Fix deletion of unrelated branch on worktree
	fd7b5bc3	2018-04-20T12:54:41		Fix deletion of unrelated branch on worktree Signed-off-by: Sven Strickroth <email@cs-ware.de>
	eb0a3afd	2018-03-11T15:35:56		worktree: Read worktree specific reflog for HEAD Signed-off-by: Sven Strickroth <email@cs-ware.de>
	9e94b6af	2017-12-30T00:12:46		iterator: cleanups with symlink dir handling Perform some error checking when examining symlink directories.
	e9628e7b	2017-10-30T11:38:33		branches: Check symlinked subdirectories Native Git allows symlinked directories under .git/refs. This change allows libgit2 to also look for references that live under symlinked directories. Signed-off-by: Andy Doan <andy@opensourcefoundries.com>
	0c7f49dd	2017-06-30T13:39:01		Make sure to always include "common.h" first 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.
	6c23704d	2017-06-08T21:40:18		settings: rename `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION` Initially, the setting has been solely used to enable the use of `fsync()` when creating objects. Since then, the use has been extended to also cover references and index files. As the option is not yet part of any release, we can still correct this by renaming the option to something more sensible, indicating not only correlation to objects. This commit renames the option to `GIT_OPT_ENABLE_FSYNC_GITDIR`. We also move the variable from the object to repository source code.
	90388aa8	2017-06-06T15:02:23		refdb_fs: be explicit about using null-OID if we cannot resolve ref
	f623cf89	2017-03-22T20:32:55		Merge pull request #4163 from pks-t/pks/submodules-with-worktrees Worktree fixes
	6fd6c678	2017-03-22T20:29:22		Merge pull request #4030 from libgit2/ethomson/fsync fsync all the things
	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.
	83580562	2017-03-06T13:14:47		refdb_fs: honor the namespace
	1c04a96b	2017-02-28T12:29:29		Honor `core.fsyncObjectFiles`
	2a5ad7d0	2017-02-17T16:42:40		fsync: call it "synchronous" object writing Rename `GIT_OPT_ENABLE_SYNCHRONIZED_OBJECT_CREATION` -> `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION`.
	eb56ed81	2016-12-15T14:49:43		refdb_fs: optionally fsync packed refs
	af3dcb0e	2016-12-15T10:56:52		refdb_fs: optionally fsync loose references
	13c3bc9a	2017-01-27T14:32:23		strmap: remove GIT__USE_STRMAP macro
	6da6b425	2017-02-14T11:13:32		refdb: catch additional per-worktree refs The upstream git.git project currently identifies all references inside of `refs/bisect/` as well as `HEAD` as per-worktree references. This is already incorrect and is currently being fixed by an in-flight topic [1]. The new behavior will be to match all pseudo-references outside of the `refs/` hierarchy as well as `refs/bisect/`. Our current behavior is to mark a selection of pseudo-references as per-worktree, only. This matches more pseudo-references than current git, but forgets about `refs/bisect/`. Adjust behavior to match the in-flight topic, that is classify the following references as per-worktree: - everything outside of `refs/` - everything inside of `refs/bisect/` [1]: <20170213152011.12050-1-pclouds@gmail.com>
	84f56cb0	2016-11-04T11:59:52		repository: rename `path_repository` and `path_gitlink` The `path_repository` variable is actually confusing to think about, as it is not always clear what the repository actually is. It may either be the path to the folder containing worktree and .git directory, the path to .git itself, a worktree or something entirely different. Actually, the intent of the variable is to hold the path to the gitdir, which is either the .git directory or the bare repository. Rename the variable to `gitdir` to avoid confusion. While at it, also rename `path_gitlink` to `gitlink` to improve consistency.
	e9403024	2015-09-24T15:32:26		refdb: look for reflog in commondir
	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.
	71dd0861	2015-09-17T11:40:55		refdb: rename refdb_fs_backend's .path to .gitpath 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.
	909d5494	2016-12-29T12:25:15		giterr_set: consistent error messages Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
	6ab65b80	2016-12-11T17:56:38		refdb: bubble up recursive rm when locking a ref Failure to bubble up this error means some locking errors do not get reported as such on Windows.