summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * khash: avoid using `kh_clear` directlyPatrick Steinhardt2017-02-172-2/+2
| |
| * khash: avoid using `kh_get` directlyPatrick Steinhardt2017-02-176-12/+12
| |
| * khash: avoid using `kh_end` directlyPatrick Steinhardt2017-02-177-13/+16
| |
| * khash: use `git_map_exists` where applicablePatrick Steinhardt2017-02-175-12/+6
| |
| * khash: avoid using `kh_foreach`/`kh_foreach_value` directlyPatrick Steinhardt2017-02-176-32/+17
| |
| * khash: avoid using `kh_size` directlyPatrick Steinhardt2017-02-173-7/+7
| |
| * offmap: remove unused macro `git_offmap_insert2`Patrick Steinhardt2017-02-171-10/+0
| |
| * strmap: remove unused macro `git_strmap_insert2`Patrick Steinhardt2017-02-171-10/+0
|/
* Merge pull request #4124 from pks-t/pks/worktree-refsPatrick Steinhardt2017-02-171-4/+9
|\ | | | | refdb: catch additional per-worktree refs
| * refdb: catch additional per-worktree refsPatrick Steinhardt2017-02-151-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge pull request #4127 from Uncommon/commentEdward Thomson2017-02-161-6/+7
|\ \ | |/ |/| Minor comment fix
| * Minor comment fixDavid Catmull2017-02-161-6/+7
|/
* Merge pull request #4122 from pks-t/pks/signature-dbl-freeEdward Thomson2017-02-133-8/+13
|\ | | | | Signature cleanups
| * commit: avoid possible use-after-freePatrick Steinhardt2017-02-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | When extracting a commit's signature, we first free the object and only afterwards put its signature contents into the result buffer. This works in most cases - the free'd object will normally be cached anyway, so we only end up decrementing its reference count without actually freeing its contents. But in some more exotic setups, where caching is disabled, this can definitly be a problem, as we might be the only instance currently holding a reference to this object. Fix this issue by first extracting the contents and freeing the object afterwards only.
| * commit: clear user-provided buffersPatrick Steinhardt2017-02-132-6/+9
| | | | | | | | | | | | | | | | | | | | The functions `git_commit_header_field` and `git_commit_extract_signature` both receive buffers used to hand back the results to the user. While these functions called `git_buf_sanitize` on these buffers, this is not the right thing to do, as it will simply initialize or zero-terminate passed buffers. As we want to overwrite contents, we instead have to call `git_buf_clear` to completely reset them.
| * buffer: clarify how `git_buf_sanitize` handles non-NULL inputPatrick Steinhardt2017-02-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | When `git_buf_sanitize` gets called, it converts a buffer with NULL content to be correctly initialized. This is done by pointing it to `git_buf__initbuf`. While the method's documentation states this clearly, it may also lead to the conclusion that it will do the same to buffers which do _not_ have NULL contents. Clarify behavior when passing a buffer with non-NULL contents, where `git_buf_sanitize` will ensure that the contents are `\0`-terminated.
* | Merge pull request #4115 from gsaralms/users/gsaral/optionalOfsDeltaEdward Thomson2017-02-134-1/+21
|\ \ | |/ |/| Changes to provide option to turn off/on ofs_delta
| * Changes to provide option to turn off/on ofs_deltaGaurav Saral2017-02-104-1/+21
| | | | | | | | This change provides an option in git_libgit2_opt_t which can be used in git_libgit2_opts to turn off/on ofs_delta capability in libGit2
* | Merge pull request #3436 from pks-t/libgit2-worktreeEdward Thomson2017-02-1375-123/+2423
|\ \ | | | | | | Worktree implementation
| * | worktree: extract git_worktree_is_prunablePatrick Steinhardt2017-02-132-7/+35
| | |
| * | worktree: test opening worktree via gitlink, gitdir and worktreePatrick Steinhardt2017-02-131-4/+77
| | |
| * | worktree: test creating and opening submodule worktreesPatrick Steinhardt2017-02-131-0/+28
| | |
| * | worktree: test opening discovered submodule worktreesPatrick Steinhardt2017-02-131-0/+27
| | |
| * | worktree: compute workdir for worktrees opened via their gitdirPatrick Steinhardt2017-02-135-12/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | repository: rename `path_repository` and `path_gitlink`Patrick Steinhardt2017-02-1310-50/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | repository: restrict checking out checked out branchesPatrick Steinhardt2017-02-132-0/+41
| | | | | | | | | | | | | | | | | | 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.
| * | branch: restrict branch deletion for worktreesPatrick Steinhardt2017-02-132-0/+33
| | | | | | | | | | | | | | | Restrict the ability to delete branches that are checked out in any linked repository.
| * | branch: implement `git_branch_is_checked_out`Patrick Steinhardt2017-02-132-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | Implement a new function that is able to determine if a branch is checked out in any repository connected to the current repository. In particular, this is required to check if for a given repository and branch, there exists any working tree connected to that repository that is referencing this branch.
| * | worktree: test basic merge functionalityPatrick Steinhardt2017-02-131-0/+121
| | |
| * | worktree: implement functions reading HEADPatrick Steinhardt2017-02-135-1/+175
| | | | | | | | | | | | | | | | | | Implement `git_repository_head_for_worktree` and `git_repository_head_detached_for_worktree` for directly accessing a worktree's HEAD without opening it as a `git_repository` first.
| * | worktree: implement `git_worktree_prune`Patrick Steinhardt2017-02-133-0/+148
| | | | | | | | | | | | | | | | | | | | | Implement the `git_worktree_prune` function. This function can be used to delete working trees from a repository. According to the flags passed to it, it can either delete the working tree's gitdir only or both gitdir and the working directory.
| * | worktree: implement locking mechanismsPatrick Steinhardt2017-02-134-0/+170
| | | | | | | | | | | | | | | | | | 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.
| * | worktree: implement `git_worktree_add`Patrick Steinhardt2017-02-133-1/+199
| | | | | | | | | | | | | | | Implement the `git_worktree_add` function which can be used to create new working trees for a given repository.
| * | worktree: implement `git_worktree_validate`Patrick Steinhardt2017-02-134-0/+101
| | | | | | | | | | | | | | | | | | 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.
| * | worktree: implement `git_repository_open_from_worktree`Patrick Steinhardt2017-02-133-0/+114
| | | | | | | | | | | | | | | Add function `git_repository_open_from_worktree`, which allows to open a `git_worktree` as repository.
| * | worktree: introduce `struct git_worktree`Patrick Steinhardt2017-02-135-1/+167
| | | | | | | | | | | | | | | | | | | | | 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.
| * | worktree: implement `git_worktree_list`Patrick Steinhardt2017-02-133-0/+202
| | | | | | | | | | | | | | | | | | Add new module for working trees with the `git_worktree_list` function. The function lists names for all working trees of a certain repository.
| * | repository: expose `repo_init_create_head`Patrick Steinhardt2017-02-132-2/+3
| | | | | | | | | | | | | | | Expose the function `repo_init_create_head` as `git_repository_create_head`.
| * | config: open configuration in commondirPatrick Steinhardt2017-02-132-2/+46
| | | | | | | | | | | | | | | | | | | | | 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.
| * | refdb: look for reflog in commondirPatrick Steinhardt2017-02-132-1/+66
| | |
| * | refdb: introduce commondir awarenessPatrick Steinhardt2017-02-132-6/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | refdb: rename refdb_fs_backend's .path to .gitpathPatrick Steinhardt2017-02-131-29/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | repository: introduce is_worktree variablePatrick Steinhardt2017-02-134-0/+31
| | |
| * | repository: use `git_repository_item_path`Patrick Steinhardt2017-02-139-27/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | repository: add function to retrieve paths for repo itemsPatrick Steinhardt2017-02-132-0/+97
| | |
| * | repository: introduce commondir variablePatrick Steinhardt2017-02-134-15/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | tests: implement worktree helpersPatrick Steinhardt2017-02-132-0/+41
| | |
| * | tests: add merge-conflict branch for testrepoPatrick Steinhardt2017-02-137-4/+6
| | | | | | | | | | | | | | | Add a new branch that causes a merge conflict to `testrepo` so that we are able to test merging in worktrees.
| * | tests: add submodule worktree test dataPatrick Steinhardt2017-02-1323-0/+24
| | | | | | | | | | | | | | | | | | 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.
| * | tests: add worktree test dataPatrick Steinhardt2017-02-1314-3/+16
| | |
View Lorry Controller Status