|
8db9fd3b
|
2019-02-02T19:00:41
|
|
refdb: documentation
|
|
5fc27aac
|
2019-08-27T13:38:08
|
|
Merge pull request #5208 from mkostyuk/apply-removed-new-file
apply: git_apply_to_tree fails to apply patches that add new files
|
|
|
5498c318
|
2019-08-27T13:10:53
|
|
apply: free test data
|
|
|
6de48085
|
2019-08-27T11:29:24
|
|
Merge pull request #5189 from libgit2/ethomson/attrs_from_head
Optionally read `.gitattributes` from HEAD
|
|
|
aaa48d06
|
2019-08-27T11:26:50
|
|
Merge pull request #5196 from pks-t/pks/config-include-onbranch
config: implement "onbranch" conditional
|
|
|
4e20c7b1
|
2019-08-25T22:11:39
|
|
Merge pull request #5213 from boardwalk/dskorupski/fix_include_case
Fix include casing for case-sensitive filesystems.
|
|
44d5e47d
|
2019-08-24T10:39:56
|
|
Fix include casing for case-sensitive filesystems.
|
|
|
60319788
|
2019-08-23T09:58:15
|
|
Merge pull request #5054 from tniessen/util-use-64-bit-timer
util: use 64 bit timer on Windows
|
|
|
feac5945
|
2019-08-23T09:42:35
|
|
Merge pull request #5200 from pks-t/pks/memory-allocation-audit
Memory allocation audit
|
|
8cbef12d
|
2019-08-08T11:52:54
|
|
util: do not perform allocations in insertsort
Our hand-rolled fallback sorting function `git__insertsort_r` does an
in-place sort of the given array. As elements may not necessarily be
pointers, it needs a way of swapping two values of arbitrary size, which
is currently implemented by allocating a temporary buffer of the
element's size. This is problematic, though, as the emulated `qsort`
interface doesn't provide any return values and thus cannot signal an
error if allocation of that temporary buffer has failed.
Convert the function to swap via a temporary buffer allocated on the
stack. Like this, it can `memcpy` contents of both elements in small
batches without requiring a heap allocation. The buffer size has been
chosen such that in most cases, a single iteration of copying will
suffice. Most importantly, it can fully contain `git_oid` structures and
pointers.
Add a bunch of tests for the `git__qsort_r` interface to verify nothing
breaks. Furthermore, this removes the declaration of `git__insertsort_r`
and makes it static as it is not used anywhere else.
|
|
|
d4fe402b
|
2019-08-08T10:36:33
|
|
merge: check return value of `git_commit_list_insert`
The function `git_commit_list_insert` dynamically allocates memory and
may thus fail to insert a given commit, but we didn't check for that in
several places in "merge.c".
Convert surrounding functions to return error codes and check whether
`git_commit_list_insert` was successful, returning an error if not.
|
|
|
c0486188
|
2019-08-08T10:28:09
|
|
blame_git: detect memory allocation errors
The code in "blame_git.c" was mostly imported from git.git with only
minor changes. One of these changes was to use our own allocators
instead of git's `xmalloc`, but there's a subtle difference: `xmalloc`
would abort the program if unable to allocate any memory, bit
`git__malloc` doesn't. As we didn't check for memory allocation errors
in some places, we might inadvertently dereference a `NULL` pointer in
out-of-memory situations.
Convert multiple functions to return proper error codes and add calls to
`GIT_ERROR_CHECK_ALLOC` to fix this.
|
|
|
f3b3e543
|
2019-08-08T11:34:01
|
|
xdiff: catch memory allocation errors
The xdiff code contains multiple call sites where the results of
`xdl_malloc` are not being checked for memory allocation errors.
Add checks to fix possible segfaults due to `NULL` pointer accesses.
|
|
|
c2dd895a
|
2019-08-08T10:47:29
|
|
transports: http: check for memory allocation failures
When allocating a chunk that is used to write to HTTP streams, we do not
check for memory allocation errors. This may lead us to write to a
`NULL` pointer and thus cause a segfault.
Fix this by adding a call to `GIT_ERROR_CHECK_ALLOC`.
|
|
|
08699541
|
2019-08-08T10:46:42
|
|
trailer: check for memory allocation errors
The "trailer.c" code has been copied mostly verbatim from git.git with
minor adjustments, only. As git.git's `xmalloc` function, which aborts
on memory allocation errors, has been swapped out for `git_malloc`,
which doesn't abort, we may inadvertently access `NULL` pointers.
Add checks to fix this.
|
|
|
8c7d9761
|
2019-08-08T10:45:12
|
|
posix: fix direct use of `malloc`
In "posix.c" there are multiple callsites which execute `malloc` instead
of `git__malloc`. Thus, users of library are not able to track these
allocations with a custom allocator.
Convert these call sites to use `git__malloc` instead.
|
|
|
a477bff1
|
2019-08-08T10:44:57
|
|
indexer: catch OOM when adding expected OIDs
When adding OIDs to the indexer's map of yet-to-be-seen OIDs to verify
that packfiles are complete, we do so by first allocating a new OID and
then calling `git_oidmap_set` on it. There was no check for memory
allocation errors in place, though, leading to possible segfaults due to
trying to copy data to a `NULL` pointer.
Verify the result of `git__malloc` with `GIT_ERROR_CHECK_ALLOC` to fix
the issue.
|
|
dceedbb8
|
2019-08-21T15:03:50
|
|
apply: Test for git_apply_to_tree failures when new files are added
Introduce an unit test to validate if git_apply_to_tree() fails when an
applied patch adds new files.
|
|
|
de4bc2bd
|
2019-08-20T03:29:45
|
|
apply: git_apply_to_tree fails to apply patches that add new files
git_apply_to_tree() cannot be used apply patches with new files. An attempt
to apply such a patch fails because git_apply_to_tree() tries to remove a
non-existing file from an old index.
The solution is to modify git_apply_to_tree() to git_index_remove() when the
patch states that the modified files is removed.
|
|
071750a3
|
2019-08-15T14:18:26
|
|
cmake: move _WIN32_WINNT definitions to root
|
|
|
0f40e68e
|
2019-08-14T09:05:07
|
|
Merge pull request #5187 from ianhattendorf/fix/clone-whitespace
clone: don't decode URL percent encodings
|
|
|
08cfa43d
|
2019-08-13T18:17:11
|
|
Merge pull request #5202 from libgit2/users/ethomson/security_updates
Security updates from 0.28.3
|
|
|
df3f18ac
|
2019-08-05T00:32:11
|
|
changelog: include security updates
|
|
|
57a9ccd5
|
2019-06-21T15:53:54
|
|
commit_list: fix possible buffer overflow in `commit_quick_parse`
The function `commit_quick_parse` provides a way to quickly parse
parts of a commit without storing or verifying most of its
metadata. The first thing it does is calculating the number of
parents by skipping "parent " lines until it finds the first
non-parent line. Afterwards, this parent count is passed to
`alloc_parents`, which will allocate an array to store all the
parent.
To calculate the amount of storage required for the parents
array, `alloc_parents` simply multiplicates the number of parents
with the respective elements's size. This already screams "buffer
overflow", and in fact this problem is getting worse by the
result being cast to an `uint32_t`.
In fact, triggering this is possible: git-hash-object(1) will
happily write a commit with multiple millions of parents for you.
I've stopped at 67,108,864 parents as git-hash-object(1)
unfortunately soaks up the complete object without streaming
anything to disk and thus will cause an OOM situation at a later
point. The point here is: this commit was about 4.1GB of size but
compressed down to 24MB and thus easy to distribute.
The above doesn't yet trigger the buffer overflow, thus. As the
array's elements are all pointers which are 8 bytes on 64 bit, we
need a total of 536,870,912 parents to trigger the overflow to
`0`. The effect is that we're now underallocating the array
and do an out-of-bound writes. As the buffer is kindly provided
by the adversary, this may easily result in code execution.
Extrapolating from the test file with 67m commits to the one with
536m commits results in a factor of 8. Thus the uncompressed
contents would be about 32GB in size and the compressed ones
192MB. While still easily distributable via the network, only
servers will have that amount of RAM and not cause an
out-of-memory condition previous to triggering the overflow. This
at least makes this attack not an easy vector for client-side use
of libgit2.
|
|
cb1439c9
|
2019-06-19T12:59:27
|
|
config: validate ownership of C:\ProgramData\Git\config before using it
When the VirtualStore feature is in effect, it is safe to let random
users write into C:\ProgramData because other users won't see those
files. This seemed to be the case when we introduced support for
C:\ProgramData\Git\config.
However, when that feature is not in effect (which seems to be the case
in newer Windows 10 versions), we'd rather not use those files unless
they come from a trusted source, such as an administrator.
This change imitates the strategy chosen by PowerShell's native OpenSSH
port to Windows regarding host key files: if a system file is owned
neither by an administrator, a system account, or the current user, it
is ignored.
|
|
62b80138
|
2019-08-13T09:10:10
|
|
clone: Remove whitespace ssh test
Will add later when infrastructure is configured
|
|
|
b15e7f2d
|
2019-08-12T09:56:51
|
|
clone: Update whitespace test url
|
|
|
5774b2b1
|
2019-08-11T23:42:45
|
|
Merge pull request #5113 from pks-t/pks/stash-perf
stash: avoid recomputing tree when committing worktree
|
|
|
cdbbb364
|
2019-07-21T16:25:41
|
|
filter: test second-level in-repo `.gitattributes`
Ensure that a `.gitattributes` file that is deeper in the tree is
honored, not just an attributes file at the root.
|
|
|
ff25ec83
|
2019-07-21T16:25:11
|
|
tests: add a subdirectory to crlf tests
Add a subdirectory in the crlf.git bare repository that has a
second-level .gitattribute file.
|
|
|
3661e35e
|
2019-06-23T23:52:24
|
|
filter: test we can filter a blob in a bare repo
|
|
|
42bacbc6
|
2019-08-11T21:06:19
|
|
Merge pull request #5121 from pks-t/pks/variadic-errors
Variadic macros
|
|
|
fba3bf79
|
2019-07-21T14:15:12
|
|
blob: optionally read attributes from repository
When `GIT_BLOB_FILTER_ATTTRIBUTES_FROM_HEAD` is passed to
`git_blob_filter`, read attributes from `gitattributes` files that
are checked in to the repository at the HEAD revision. This passes
the flag `GIT_FILTER_ATTRIBUTES_FROM_HEAD` to the filter functions.
|
|
|
f0f27c1c
|
2019-07-21T14:13:25
|
|
filter: optionally read attributes from repository
When `GIT_FILTER_ATTRIBUTES_FROM_HEAD` is specified, configure the
filter to read filter attributes from `gitattributes` files that are
checked in to the repository at the HEAD revision. This passes the flag
`GIT_ATTR_CHECK_INCLUDE_HEAD` to the attribute reading functions.
|
|
|
4fd5748c
|
2019-07-21T14:11:03
|
|
attr: optionally read attributes from repository
When `GIT_ATTR_CHECK_INCLUDE_HEAD` is specified, read `gitattribute`
files that are checked into the repository at the HEAD revision.
|
|
|
a5392eae
|
2019-07-21T12:13:07
|
|
blob: allow blob filtering to ignore system gitattributes
Introduce `GIT_BLOB_FILTER_NO_SYSTEM_ATTRIBUTES`, which tells
`git_blob_filter` to ignore the system-wide attributes file, usually
`/etc/gitattributes`.
This simply passes the appropriate flag to the attribute loading code.
|
|
|
22eb12af
|
2019-07-21T12:12:05
|
|
filter: add GIT_FILTER_NO_SYSTEM_ATTRIBUTES option
Allow system-wide attributes (the ones specified in
`/etc/gitattributes`) to be ignored if the flag
`GIT_FILTER_NO_SYSTEM_ATTRIBUTES` is specified.
|
|
|
e7fc8601
|
2019-07-21T11:53:29
|
|
filter: test that system attributes can be ignored
Test that we can optionally ignore system attributes when filtering a
blob.
|
|
|
45ddb586
|
2019-07-21T12:14:50
|
|
filter: document GIT_FILTER_ALLOW_UNSAFE
|
|
|
c66f7605
|
2019-07-21T11:44:11
|
|
filter: ensure system attributes are read
By default, `/etc/gitattributes` (or the system equivalent) is read to
provide attributes. Ensure that, by default, this is read when
filtering blobs.
|
|
|
fa1a4c77
|
2019-07-21T11:03:01
|
|
blob: deprecate `git_blob_filtered_content`
Users should now use `git_blob_filter`.
|
|
|
a008ceea
|
2019-07-21T11:01:36
|
|
blob: convert users of git_blob_filtered_content
Move users of `git_blob_filtered_content` to `git_blob_filter`.
|
|
|
a32ab076
|
2019-07-21T10:56:42
|
|
blob: introduce git_blob_filter
Provide a function to filter blobs that allows for more functionality
than the existing `git_blob_filtered_content` function.
|
|
|
b0692d6b
|
2019-08-09T09:01:56
|
|
Merge pull request #4913 from implausible/feature/signing-rebase-commits
Add sign capability to git_rebase_commit
|
|
998f9c15
|
2019-08-07T07:21:27
|
|
fixup: strange indentation
|
|
|
f627ba6c
|
2019-08-02T13:18:07
|
|
Merge pull request #5197 from pks-t/pks/remote-ifdeffed-block
remote: remove unused block of code
|
|
|
24c491ed
|
2019-08-02T07:58:11
|
|
Merge pull request #5146 from scottfurry/StaticFixesExamples
Adjust printf specifiers in examples code
|
|
|
e23c0b18
|
2019-08-02T07:52:58
|
|
remote: remove unused block of code
In "remote.c", we have a chunk of code that is #ifdef'fed out via
`#if 0` with a comment that we could export it as a helper function.
The code was implemented in 2013 and ifdef'fed in 2014, which shows that
there's clearly no interest in having such a helper at all.
As this block has recently created some confusion about `p_getenv` due
to it containing the only reference to that function in our codebase,
let's remove this block altogether.
|
|
|
d588de7c
|
2019-08-02T07:51:02
|
|
Merge pull request #5191 from eaigner/master
config: check if we are running in a sandboxed environment
|
|
73a186f2
|
2019-06-27T10:02:40
|
|
Adjust printf specifiers in examples code
Static analysis of example code found multiple findings of `printf` usage
where filling value is members of git_indexer_progress object. Specifier
used was for signed int but git_indexer_progress members are typed as
unsigned ints. `printf` specifiers were altered to match type.
|
|
952fbbfb
|
2019-08-01T20:04:11
|
|
config: check if we are running in a sandboxed environment
On macOS the $HOME environment variable returns the path to the sandbox container instead of the actual user $HOME for sandboxed apps. To get the correct path, we have to get it from the password file entry.
|
|
|
ac171542
|
2019-08-01T17:45:14
|
|
Merge pull request #5184 from novalis/fix-example
Fix example checkout to forbid rather than require --
|
|
|
722ba93f
|
2019-08-01T15:14:06
|
|
config: implement "onbranch" conditional
With Git v2.23.0, the conditional include mechanism gained another new
conditional "onbranch". As the name says, it will cause a file to be
included if the "onbranch" pattern matches the currently checked out
branch.
Implement this new condition and add a bunch of tests.
|
|
|
e208b195
|
2019-08-01T13:42:19
|
|
tests: config: catch OOM when assembling conditional config
When assembling contents of the conditionally including file, we use
`git_buf_printf` and `git_buf_puts` without checking for error returns.
Add `cl_git_pass` to fix this.
|
|
|
835211dc
|
2019-08-01T13:23:16
|
|
tests: config: assert behaviour around includes
Add a few tests that verify some behaviour centered around includes. The
first set of tests verifies that we correctly override values depending
on the order of includes and other keys, the second set asserts that we
can correctly snapshot configuration files with includes.
|
|
|
304e58c0
|
2019-08-01T13:20:17
|
|
tests: config::snapshot: modernize tests
Modernize the tests in config::snapshot to make them easier to
understand. Most important, include a cleanup function that frees config
and snapshot and unlink config files at the end of each test.
|
|
|
8f7fd981
|
2019-08-01T13:35:27
|
|
Merge pull request #5183 from pks-t/pks/editorconfig
editorconfig: update to match our coding style
|
|
|
56e7aaf0
|
2019-08-01T12:40:51
|
|
Merge pull request #5125 from albfan/wip/albfan/diff_buffers
Compare buffers in diff example
|
|
|
1721ab04
|
2019-06-16T11:25:47
|
|
unix: posix: avoid use of variadic macro `p_snprintf`
The macro `p_snprintf` is implemented as a variadic macro that
calls `snprintf` directly with `__VA_ARGS__`. In C89, variadic
macros are not allowed, but as the arguments of `p_snprintf` and
`snprintf` are matching 1:1, we can fix this by simply removing
the parameter list from `p_snprintf`.
|
|
|
63d8cd18
|
2019-06-16T11:17:17
|
|
apply: remove use of variadic error macro
The macro `apply_err` is implemented as a variadic macro, which
are not defined by C89. Convert it to a variadic function,
instead.
|
|
|
27b8b31e
|
2019-08-01T11:57:03
|
|
parse: remove use of variadic macros which are not C89 compliant
The macro `git_parse_error` is implemented in a variadic way so
that it's possible to pass printf-style parameters.
Unfortunately, variadic macros are not defined by C89 and thus we
cannot use that functionality. But as we have implemented
`git_error_vset` in the previous commit, we can now just use that
instead.
Convert `git_parse_error` to a variadic function and use
`git_error_vset` to fix the compliance violation. While at it,
move the function to "patch_parse.c".
|
|
|
c8e63812
|
2019-06-16T11:03:08
|
|
errors: introduce `git_error_vset` function
Right now, we only provide a `git_error_set` that has a variadic
function signature. It's impossible to drive this function in a
C89-compliant way from other functions that have a variadic
signature, though, like for example `git_parse_error`.
Implement a new `git_error_vset` function that gets a `va_list`
as parameter, fixing the above problem.
|
|
|
eea128b5
|
2019-08-01T11:49:50
|
|
Merge pull request #5135 from j143-bot/jdev01
Include ahead_behind in the test suite
|
|
|
e8f63411
|
2019-08-01T11:29:58
|
|
Merge pull request #5186 from pks-t/pks/config-snapshot-separation
config: separate file and snapshot backends
|
|
|
fb0730f1
|
2019-04-16T23:49:16
|
|
util: use 64 bit timer on Windows
git__timer was originally implemented using a 32 bit timer since
Windows XP did not support GetTickCount64. Windows XP was discontinued
five years ago, so it should be safe to use the new API.
As a benefit, we do not need to care about overflows for the next 585
million years.
|
|
|
75cc755f
|
2019-07-29T18:05:35
|
|
cmake: fix _WIN32_WINNT for MinGW
|
|
f039c836
|
2019-07-29T13:02:37
|
|
Merge pull request #5192 from libgit2/cmn/object-size-nopublic
object: deprecate git_object__size for removal
|
|
c8e249b0
|
2019-07-29T10:51:22
|
|
object: deprecate git_object__size for removal
In #5118 we remove the double-underscore to make it a normally-named public
function. However, this is not an interesting function outside of the library
and it takes up a name for something that could be more useful.
Remove the single-underscore version as we have not done any releases with it.
|
|
|
37ebe9ad
|
2019-07-24T18:49:08
|
|
config_backend: rename internal structures
The internal backend structures are kind-of legacy and do not really
speak for themselves. Rename them accordingly to make them easier to
understand.
|
|
|
2bff84ba
|
2019-07-26T21:02:56
|
|
config_file: separate out read-only backend
To further distinguish the file writeable and readonly backends,
separate the readonly backend into its own "config_snapshot.c"
implementation. The snapshot backend can be generically used to snapshot
any type of backend.
|
|
|
f0b10066
|
2019-07-24T18:37:14
|
|
config_file: fix cast of readonly backend
In `backend_readonly_free`, the passed in config backend is being cast
to a `diskfile_backend` instead of to a `diskfile_readonly_backend`.
While this works out just fine because we only access its header values,
which were shared between both backends, it is undefined behaviour.
Use the correct type to fix this.
|
|
|
a3159df8
|
2019-07-24T18:31:43
|
|
config_file: remove shared `diskfile_header` struct
The `diskfile_header` structure is shared between both
`diskfile_backend` and `diskfile_readonly_backend`. The separation and
resulting casting is confusing at times and a source for programming
errors.
Remove the shared structure and inline them directly.
|
|
|
271e5fba
|
2019-07-24T18:18:18
|
|
config_file: duplicate accessors for readonly backend
While most functions of the readonly configuration backend are
implemented separately from the writeable configuration backend, the two
functions `config_iterator_new` and `config_get` are shared between
both. This sharing makes it necessary to have some shared data
structures, which is the `diskfile_header` structure. Unfortunately, this
makes the backends harder to grasp than necessary due to all the casting
between structs and also quite error prone.
Reimplement those functions for the readonly backends. As readonly
backends cannot be refreshed anyway, we can remove the calls to
`config_refresh` in there.
|
|
|
4e7ce1fb
|
2019-07-24T18:13:52
|
|
config_file: reimplement `config_readonly_open` generically
The `config_readonly_open` function currently receives as input a
diskfile backend and will copy its entries to a new snapshot. This is
rather intimate, as we need to assume that the source config backend is
in fact a diskfile entry. We can do better than this though by using
generic methods to copy contents of the provided backend, e.g. by using
a config iterator. This also allows us to decouple the read-only backend
from the read-write backend.
|
|
|
76182e84
|
2019-07-24T18:04:38
|
|
config_entries: fix possible segfault when duplicating entries
When duplicating a configuration entry, we allocate a new entry but do
not verify that we get a valid pointer back. As we're dereferencing the
pointer afterwards, we might thus run into a segfault in out-of-memory
situations.
Extract a new function `git_config_entries_dup_entry` that handles the
complete entry duplication. Fix the error by using
`GIT_ERROR_CHECK_ALLOC`.
|
|
|
42ea2f95
|
2019-07-25T13:15:10
|
|
clone: whitespace in url ssh test
|
|
|
ba2885da
|
2019-07-24T18:05:28
|
|
git_net_url_parse: don't git_buf_decode_percent for path
|
|
|
1748f92c
|
2019-07-24T16:36:45
|
|
clone: whitespace in url test
|
|
ed387d4a
|
2019-07-24T12:01:27
|
|
Fix example checkout to forbid rather than require --
Make the example program for checkout follow git syntax, where
"--" indicates a file. This was likely just a strcmp return
value confusion.
|
|
|
ab545014
|
2019-07-24T08:20:08
|
|
editorconfig: update to match our coding style
Update editorconfig to match our coding style. Most importantly, we set
up the tab width to be 8 characters instead of the default and use
2 spaces to indent YAML files.
|
|
fdd10839
|
2019-06-30T00:41:10
|
|
Implement test for graph ahead and behind
|
|
|
e3adc99e
|
2019-07-22T11:02:38
|
|
Merge pull request #5181 from pks-t/pks/config-iterator-refresh
config_file: refresh when creating an iterator
|
|
|
c0290e27
|
2019-06-23T23:52:52
|
|
filter: add a crlf blob test
Add a LF->CRLF conversion test to the blob filter.
|
|
a213fec6
|
2019-07-21T15:12:40
|
|
tests: remote: add test suite to test listing remotes
There was a bug when calling `git_remote_list` that caused us to not
re-read modified configurations when using `git_config_iterator`. This
bug also impacted `git_remote_list`, which thus failed to provide an
up-to-date list of remotes. Add a test suite remote::list with a single
test that verifies we do the right thing.
|
|
|
2766b92d
|
2019-07-21T15:10:34
|
|
config_file: refresh when creating an iterator
When creating a new iterator for a config file backend, then we should
always make sure that we're up to date by calling `config_refresh`.
Otherwise, we might not notice when another process has modified the
configuration file and thus will represent outdated values.
Add two tests to config::stress that verify that we get up-to-date
values when reading configuration entries via `git_config_iterator`.
|
|
|
9fac8b78
|
2019-07-21T15:08:22
|
|
config_file: do not refresh read-only backends
If calling `config_refresh` on a read-only configuration file backend,
then we will segfault when comparing the timestamp of the file due to
`path` being uninitialized. As a read-only snapshot should not be
refreshed anyway and stay consistent, we can simply return early when
calling `config_refresh` on a read-only snapshot.
|
|
|
28d11b59
|
2019-07-21T14:41:21
|
|
config_file: consistently use `GIT_CONTAINER_OF`
|
|
|
82b1d1da
|
2019-07-21T12:25:10
|
|
Merge pull request #5141 from pks-t/pks/azure-drop-powershell
azure: drop powershell
|
|
|
90858192
|
2019-07-20T21:30:03
|
|
Merge pull request #5180 from libgit2/ethomson/futils
fuzzer: use futils instead of fileops
|
|
|
ecd4f97b
|
2019-07-20T21:15:47
|
|
fuzzer: use futils instead of fileops
|
|
|
2376cd26
|
2019-07-20T20:48:49
|
|
Merge pull request #5151 from pks-t/pks/w32-unlink-symlink
w32: fix unlinking of directory symlinks
|
|
|
6be5ac23
|
2019-07-11T15:30:51
|
|
checkout: postpone creation of symlinks to the end
On most platforms it's fine to create symlinks to nonexisting files. Not
so on Windows, where the type of a symlink (file or directory) needs to
be set at creation time. So depending on whether the target file exists
or not, we may end up with different symlink types. This creates a
problem when performing checkouts, where we simply iterate over all blobs
that need to be updated without treating symlinks any special. If the
target file of the symlink is going to be checked out after the symlink
itself, then the symlink will be created as directory symlink and not as
file symlink.
Fix the issue by iterating over blobs twice: once to perform postponed
deletions and updates to non-symlink blobs, and once to perform updates
to symlink blobs.
|
|
|
50194dcd
|
2019-07-11T15:14:42
|
|
win32: fix symlinks to relative file targets
When creating a symlink in Windows, one needs to tell Windows whether
the symlink should be a file or directory symlink. To determine which
flag to pass, we call `GetFileAttributesW` on the target file to see
whether it is a directory and then pass the flag accordingly. The
problem though is if create a symlink with a relative target path, then
we will check that relative path while not necessarily being inside of
the working directory where the symlink is to be created. Thus, getting
its attributes will either fail or return attributes of the wrong
target.
Fix this by resolving the target path relative to the directory in which
the symlink is to be created.
|
|
|
93d37a1d
|
2019-06-29T09:59:36
|
|
tests: core: improve symlink test coverage
Add two more tests to verify that we're not deleting symlink targets,
but the symlinks themselves. Furthermore, convert several `cl_skip`s on
Win32 to conditional skips depending on whether the clar sandbox
supports symlinks or not. Windows is grown up now and may allow
unprivileged symlinks if the machine has been configured accordingly.
|
|
|
683ea2b0
|
2019-06-29T09:10:57
|
|
tests: core: add missing asserts for several function calls
Several function calls to `p_stat` and `p_close` have no verification if
they actually succeeded. As these functions _may_ fail and as we also
want to make sure that we're not doing anything dumb, let's check them,
too.
|
|
|
a00842c4
|
2019-06-29T09:59:14
|
|
win32: correctly unlink symlinks to directories
When deleting a symlink on Windows, then the way to delete it depends on
whether it is a directory symlink or a file symlink. In the first case,
we need to use `DeleteFile`, in the second `RemoveDirectory`. Right now,
`p_unlink` will only ever try to use `DeleteFile`, though, and thus fail
to remove directory symlinks. This mismatches how unlink(3P) is expected
to behave, though, as it shall remove any symlink disregarding whether
it is a file or directory symlink.
In order to correctly unlink a symlink, we thus need to check what kind
of file this is. If we were to first query file attributes of every file
upon calling `p_unlink`, then this would penalize the common case
though. Instead, we can try to first delete the file with `DeleteFile`
and only if the error returned is `ERROR_ACCESS_DENIED` will we query
file attributes and determine whether it is a directory symlink to use
`RemoveDirectory` instead.
|
|
|
ded77bb1
|
2019-06-29T09:58:34
|
|
path: extract function to check whether a path supports symlinks
When initializing a repository, we need to check whether its working
directory supports symlinks to correctly set the initial value of the
"core.symlinks" config variable. The code to check the filesystem is
reusable in other parts of our codebase, like for example in our tests
to determine whether certain tests can be expected to succeed or not.
Extract the code into a new function `git_path_supports_symlinks` to
avoid duplicate implementations. Remove a duplicate implementation in
the repo test helper code.
|
|
|
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.
|
|
|
a7d32d60
|
2019-07-20T18:46:32
|
|
stash: avoid recomputing tree when committing worktree
When creating a new stash, we need to create there separate
commits storing differences stored in the index, untracked
changes as well as differences in the working directory. The
first two will only be done conditionally if the equivalent
options "git stash --keep-index --include-untracked" are being
passed to `git_stash_save`, but even when only creating a stash
of worktree changes we're much slower than git.git. Using our new
stash example:
$ time git stash
Saved working directory and index state WIP on (no branch): 2f7d9d47575e Linux 5.1.7
real 0m0.528s
user 0m0.309s
sys 0m0.381s
$ time lg2 stash
real 0m27.165s
user 0m13.645s
sys 0m6.403s
As can be seen, libgit2 is more than 50x slower than git.git!
When creating the stash commit that includes all worktree
changes, we create a completely new index to prepare for the new
commit and populate it with the entries contained in the index'
tree. Here comes the catch: by populating the index with a tree's
contents, we do not have any stat caches in the index. This means
that we have to re-validate every single file from the worktree
and see whether it has changed.
The issue can be fixed by populating the new index with the
repo's existing index instead of with the tree. This retains all
stat cache information, and thus we really only need to check
files that have changed stat information. This is semantically
equivalent to what we previously did: previously, we used the
tree of the commit computed from the index. Now we're just using
the index directly.
And, in fact, the cache is doing wonders:
time lg2 stash
real 0m1.836s
user 0m1.166s
sys 0m0.663s
We're now performing 15x faster than before and are only 3x
slower than git.git now.
|
|
|
88731e3c
|
2019-06-14T12:34:37
|
|
examples: implement git-stash example
Implement a new example that resembles the git-stash(1) command.
Right now, it only provides the apply, list, save and pop
subcommands without any options.
This example is mostly used to test libgit2's stashing
performance on big repositories.
|