kmx git

Commit	Date	Message
e0568621	2017-07-19T13:55:55	Merge pull request #4250 from pks-t/pks/config-file-iteration Configuration file fixes with includes
a94a5402	2017-07-19T13:28:32	Merge pull request #4272 from pks-t/pks/patch-id Patch ID calculation
1b329089	2017-05-31T22:27:19	config_file: refuse modifying included variables Modifying variables pulled in by an included file currently succeeds, but it doesn't actually do what one would expect, as refreshing the configuration will cause the values to reappear. As we are currently not really able to support this use case, we will instead just return an error for deleting and setting variables which were included via an include.
28c2cc3d	2017-05-31T16:41:44	config_file: move reader into `config_read` only Right now, we have multiple call sites which initialize a `reader` structure. As the structure is only actually used inside of `config_read`, we can instead just move the reader inside of the `config_read` function. Instead, we can just pass in the configuration file into `config_read`, which eases code readability.
6f7aab0c	2017-06-06T09:45:11	tests: config::include: use init and cleanup functions
83bcd3a1	2017-05-31T22:45:25	config_file: refresh all files if includes were modified Currently, we only re-parse the top-level configuration file when it has changed itself. This can cause problems when an include is changed, as we were not updating all values correctly. Instead of conditionally reparsing only refreshed files, the logic becomes much clearer and easier to follow if we always re-parse the top-level configuration file when either the file itself or one of its included configuration files has changed on disk. This commit implements this logic. Note that this might impact performance in some cases, as we need to re-read all configuration files whenever any of the included files changed. It could increase performance to just re-parse include files which have actually changed, but this would compromise maintainability of the code without much gain. The only case where we will gain anything is when we actually use includes and when only these includes are updated, which will probably be quite an unusual scenario to actually be worthwhile to optimize.
1f7af277	2017-07-05T11:52:47	tests: config: fix missing declaration causing error On systems where we pull in our distributed version of the regex library, all tests in config::readonly fail. This error is actually quite interesting: the test suite is unable to find the declaration of `git_path_exists` and assumes it has a signature of `int git_path_exists(const char *)`. But actually, it has a `bool` return value. Due to this confusion, some wrong conversion is done by the compiler and the `cl_assert(!git_path_exists("file"))` checks erroneously fail, even when the function does in fact return the correct value. The error is actually introduced by 56893bb9a (cmake: consistently use TARGET_INCLUDE_DIRECTORIES if available, 2017-06-28), unfortunately introduced by myself. Due to the delayed addition of include directories, we will now find the "config.h" header inside of the "deps/regex" directory instead of inside the "src/" directory, where it should be. As such, we are missing definitions for the `git_config_file__ondisk` and `git_path_exists` symbols. The correct fix here would be to fix the order in which include search directories are added. But due to the current restructuring of CMakeBuild.txt, I'm refraining from doing so and delay the proper fix a bit. Instead, we paper over the issue by explicitly including "path.h" to fix its prototype. This ignores the issue that `git_config_file__ondisk` is undeclared, as its signature is correctly identified by the compiler.
89a34828	2017-06-16T13:34:43	diff: implement function to calculate patch ID The upstream git project provides the ability to calculate a so-called patch ID. Quoting from git-patch-id(1): A "patch ID" is nothing but a sum of SHA-1 of the file diffs associated with a patch, with whitespace and line numbers ignored." Patch IDs can be used to identify two patches which are probably the same thing, e.g. when a patch has been cherry-picked to another branch. This commit implements a new function `git_diff_patchid`, which gets a patch and derives an OID from the diff. Note the different terminology here: a patch in libgit2 are the differences in a single file and a diff can contain multiple patches for different files. The implementation matches the upstream implementation and should derive the same OID for the same diff. In fact, some code has been directly derived from the upstream implementation. The upstream implementation has two different modes to calculate patch IDs, which is the stable and unstable mode. The old way of calculating the patch IDs was unstable in a sense that a different ordering the diffs was leading to different results. This oversight was fixed in git 1.9, but as git tries hard to never break existing workflows, the old and unstable way is still default. The newer and stable way does not care for ordering of the diff hunks, and in fact it is the mode that should probably be used today. So right now, we only implement the stable way of generating the patch ID.
b6ed67c2	2017-05-10T12:54:14	tests: refs::crashes: create sandbox for creating symref The test `refs::crashes::double_free` operates on our in-source "testrepo.git" repository without creating a copy first. As the test will try to create a new symbolic reference, this will fail when we want to do a pure out-of-tree build with a read-only source tree. Fix the issue by creating a sandbox first.
6ee7d37a	2017-05-10T12:51:06	tests: index::tests: create sandboxed repo for locking The test `index::tests::can_lock_index` operates on the "testrepo.git" repository located inside of our source tree. While this is okay for tests which do read-only operations on these resouces, this specific test tries to lock the index by creating a lock. This will obviously fail on out-of-tree builds with read-only source trees. Fix the issue by creating a sandbox first.
8d22bcea	2017-05-10T12:21:53	generate.py: generate clar cache in binary directory The source directory should usually not be touched when using out-of-tree builds. But next to the previously fixed "clar.suite" file, we are also writing the ".clarcache" into the project's source tree, breaking the builds. Fix this by also honoring the output directory for the ".clarcache" file.
9e240bd2	2017-05-10T12:02:03	generate.py: enable overriding path of generated clar.suite The generate.py script will currently always write the generated clar.suite file into the scanned directory, breaking out-of-tree builds with read-only source directories. Fix this issue by adding another option to allow overriding the output path of the generated file.
0a513a94	2017-05-10T11:46:00	generate.py: disallow generating test suites for multiple paths Our generate.py script is used to extract and write test suite declarations into the clar.suite file. As is, the script accepts multiple directories on the command line and will generate this file for each of these directories. The generate.py script will always write the clar.suite file into the directory which is about to be scanned. This actually breaks out-of-tree builds with libgit2, as the file will be generated in the source tree instead of in the build tree. This is noticed especially in the case where the source tree is mounted read-only, rendering us unable to build unit tests. Due to us accepting multiple paths which are to be scanned, it is not trivial to fix though. The first solution which comes into mind would be to re-create the directory hierarchy at a given output path or use unique names for the clar.suite files, but this is rather cumbersome and magical. The second and cleaner solution would be to fold all directories into a single clar.suite file, but this would probably break some use-cases. Seeing that we do not ever pass multiple directories to generate.py, we will now simply retire support for this. This allows us to later on introduce an additional option to specify the path where the clar.suite file will be generated at, defaulting to "clar.suite" inside of the scanned directory.
62c44c49	2017-06-21T12:25:26	Merge pull request #4211 from pks-t/pks/trusty travis: upgrade container to Ubuntu 14.04
c2c95ad0	2017-04-26T13:16:18	tests: online::clone: use URL of test server All our tests running against a local SSH server usually read the server's URL from environment variables. But online::clone::ssh_cert test fails to do so and instead always connects to "ssh://localhost/foo". This assumption breaks whenever the SSH server is not running on the standard port, e.g. when it is running as a user. Fix the issue by using the URL provided by the environment.
8e912e79	2017-06-16T21:05:58	tests: try to init with empty template path
8296da5f	2017-06-14T10:49:28	Merge pull request #4267 from mohseenrm/master adding GIT_FILTER_VERSION to GIT_FILTER_INIT as part of convention
a78441bc	2017-06-13T11:05:40	Adding git_filter_init for initializing `git_filter` struct + unit test
a180e7d9	2017-06-13T11:10:19	tests: odb: add more low-level backend tests Introduce a new test suite "odb::backend::simple", which utilizes the fake backend to exercise the ODB abstraction layer. While such tests already exist for the case where multiple backends are put together, no direct testing for functionality with a single backend exist yet.
b2e53f36	2017-06-13T11:39:36	tests: odb: implement `exists_prefix` for the fake backend The fake backend currently implements all reading functions except for the `exists_prefix` one. Implement it to enable further testing of the ODB layer.
983e627d	2017-06-13T11:38:59	tests: odb: use correct OID length The `search_object` function takes the OID length as one of its parameters, where its maximum length is `GIT_OID_HEXSZ`. The `exists` function of the fake backend used `GIT_OID_RAWSZ` though, leading to only the first half of the OID being used when finding the correct object.
c4cbb3b1	2017-06-13T11:38:14	tests: odb: have the fake backend detect ambiguous prefixes In order to be able to test the ODB prefix functions, we need to be able to detect ambiguous prefixes in case multiple objects with the same prefix exist in the fake ODB. Extend `search_object` to detect ambiguous queries and have callers return its error code instead of always returning `GIT_ENOTFOUND`.
95170294	2017-06-13T11:08:28	tests: core: test initialization of `git_proxy_options` Initialization of the `git_proxy_options` structure is never tested anywhere. Include it in our usual initialization test in "core::structinit::compare".
bee423cc	2017-06-13T10:29:23	tests: network: add missing include for `git_repository_new` A newly added test uses the `git_repository_new` function without the corresponding header file being included. While this works due to the compiler deducing the correct function signature, we should obviously just include the function's declaration file.
2ca088bd	2017-06-12T22:47:54	Merge pull request #4265 from pks-t/pks/read-prefix-tests Read prefix tests
fe9a5dd3	2017-06-12T12:00:14	remote: ensure we can create an anon remote on inmemory repo Given a wholly in-memory repository, ensure that we can create an anonymous remote and perform actions on it.
f148258a	2017-06-12T16:19:45	tests: odb: add tests with multiple backends Previous to pulling out and extending the fake backend, it was quite cumbersome to write tests for very specific scenarios regarding backends. But as we have made it more generic, it has become much easier to do so. As such, this commit adds multiple tests for scenarios with multiple backends for the ODB. The changes also include a test for a very targeted scenario. When one backend found a matching object via `read_prefix`, but the last backend returns `GIT_ENOTFOUND` and when object hash verification is turned off, we fail to reset the error code to `GIT_OK`. This causes us to segfault later on, when doing a double-free on the returned object.
6e010bb1	2017-06-12T15:43:56	tests: odb: allow passing fake objects to the fake backend Right now, the fake backend is quite restrained in the way how it works: we pass it an OID which it is to return later as well as an error code we want it to return. While this is sufficient for existing tests, we can make the fake backend a little bit more generic in order to allow us testing for additional scenarios. To do so, we change the backend to not accept an error code and OID which it is to return for queries, but instead a simple array of OIDs with their respective blob contents. On each query, the fake backend simply iterates through this array and returns the first matching object.
369cb45f	2017-06-12T15:21:58	tests: do not reuse OID from backend In order to make the fake backend more useful, we want to enable it holding multiple object references. To do so, we need to decouple it from the single fake OID it currently holds, which we simply move up into the calling tests.
2add34d0	2017-06-12T14:53:46	tests: odb: move fake backend into its own file The fake backend used by the test suite `odb::backend::nonrefreshing` is useful to have some low-level tests for the ODB layer. As such, we move the implementation into its own `backend_helpers` module.
6f960b55	2017-06-11T10:37:46	Merge pull request #4088 from chescock/packfile-name-using-complete-hash Ensure packfiles with different contents have different names
d2c4f764	2017-06-11T09:54:04	Merge pull request #4260 from libgit2/ethomson/forced_checkout_2 Update to forced checkout and untracked files
0ef405b3	2017-02-15T14:05:10	checkout: do not delete directories with untracked entries If the `GIT_CHECKOUT_FORCE` flag is given to any of the `git_checkout` invocations, we remove files which were previously staged. But while doing so, we unfortunately also remove unstaged files in a directory which contains at least one staged file, resulting in potential data loss. This commit adds two tests to verify behavior.
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.
92d3ea4e	2017-05-19T13:04:32	tests: index::version: improve write test for index v4 The current write test does not trigger some edge-cases in the index version 4 path compression code. Rewrite the test to start off the an empty standard repository, creating index entries with interesting paths itself. This allows for more fine-grained control over checked paths. Furthermore, we now also verify that entry paths are actually reconstructed correctly.
8fe33538	2017-05-19T12:45:48	tests: index::version: verify we write compressed index entries While we do have a test which checks whether a written index of version 4 has the correct version set, we do not check whether this actually enables path compression for index entries. This commit adds a new test by adding a number of index entries with equal path prefixes to the index and subsequently flushing that to disk. With suffix compression enabled by index version 4, only the last few bytes of these paths will actually have to be written to the index, saving a lot of disk space. For the test, differences are about an order of magnitude, allowing us to easily verify without taking a deeper look at actual on-disk contents.
82368b1b	2017-05-12T10:04:42	tests: index::version: add test to read index version v4 While we have a simple test to determine whether we can write an index of version 4, we never verified that we are able to read this kind of index (and in fact, we were not able to do so). Add a new repository which has an index of version 4. This repository is then read from a new test.
fea0c81e	2017-05-12T09:09:07	tests: index::version: move up cleanup function The init and cleanup functions for test suites are usually prepended to our actual tests. The index::version test suite does not adhere to this stile. Fix this.
8a5e7aae	2017-05-22T12:53:44	varint: fix computation for remaining buffer space When encoding varints to a buffer, we want to remain sure that the required buffer space does not exceed what is actually available. Our current check does not do the right thing, though, in that it does not honor that our `pos` variable counts the position down instead of up. As such, we will require too much memory for small varints and not enough memory for big varints. Fix the issue by correctly calculating the required size as `(sizeof(varint) - pos)`. Add a test which failed before.
dd0aa811	2017-06-04T22:46:07	Merge branch 'pr/4228'
82e929a8	2017-06-04T19:35:39	Merge pull request #4239 from roblg/toplevel-dir-ignore-fix Fix issue with directory glob ignore in subdirectories
04de614b	2017-06-04T19:03:07	Merge pull request #4243 from pks-t/pks/submodule-workdir Submodule working directory
a1023a43	2017-05-20T17:18:07	Merge pull request #4179 from libgit2/ethomson/expand_tilde Introduce home directory expansion function for config files, attribute files
e694e4e9	2017-05-20T14:17:36	Merge pull request #4174 from libgit2/ethomson/set_head_to_tag git_repository_set_head: use tag name in reflog
119bdd86	2017-05-20T14:13:27	Merge pull request #4231 from wabain/open-revrange revparse: support open-ended ranges
c0e54155	2017-01-11T10:39:59	indexer: name pack files after trailer hash Upstream git.git has changed the way how packfiles are named. Previously, they were using a hash of the contained object's OIDs, which has then been changed to use the hash of the complete packfile instead. See 1190a1acf (pack-objects: name pack files after trailer hash, 2013-12-05) in the git.git repository for more information on this change. This commit changes our logic to match the behavior of core git.
2696c5c3	2017-05-19T09:21:17	repository: make check if repo is a worktree more strict To determine if a repository is a worktree or not, we currently check for the existence of a "gitdir" file inside of the repository's gitdir. While this is sufficient for non-broken repositories, we have at least one case of a subtly broken repository where there exists a gitdir file inside of a gitmodule. This will cause us to misidentify the submodule as a worktree. While this is not really a fault of ours, we can do better here by observing that a repository can only ever be a worktree iff its common directory and dotgit directory are different. This allows us to make our check whether a repo is a worktree or not more strict by doing a simple string comparison of these two directories. This will also allow us to do the right thing in the above case of a broken repository, as for submodules these directories will be the same. At the same time, this allows us to skip the `stat` check for the "gitdir" file for most repositories.
c3b8e8b3	2017-05-14T10:28:05	Fix issue with directory glob ignore in subdirectories
e526fbc7	2017-05-17T09:23:06	tests: add test suite for opening submodules
98a5f081	2017-05-03T13:53:13	tests: threads::basic: remove unused function `exit_abruptly`
7d7f6d33	2017-05-03T13:52:55	tests: clone::local: compile UNC functions for Windows only
8b107dc5	2017-05-03T11:20:57	revparse: support open-ended ranges Support '..' and '...' ranges where one side is not specified. The unspecified side defaults to HEAD. Closes #4223
883eeb5f	2017-05-02T12:35:59	worktree: switch over worktree pruning to an opts structure The current signature of `git_worktree_prune` accepts a flags field to alter its behavior. This is not as flexible as we'd like it to be when we want to enable passing additional options in the future. As the function has not been part of any release yet, we are still free to alter its current signature. This commit does so by using our usual pattern of an options structure, which is easily extendable without breaking the API.
8264a30f	2017-05-02T10:11:28	worktree: support creating locked worktrees When creating a new worktree, we do have a potential race with us creating the worktree and another process trying to delete the same worktree as it is being created. As such, the upstream git project has introduced a flag `git worktree add --locked`, which will cause the newly created worktree to be locked immediately after its creation. This mitigates the race condition. We want to be able to mirror the same behavior. As such, a new flag `locked` is added to the options structure of `git_worktree_add` which allows the user to enable this behavior.
ffd264d9	2017-05-03T14:51:23	tests: repo: fix repo discovery tests on overlayfs Debian and Ubuntu often use schroot to build their DEB packages in a controlled environment. Depending on how schroot is configured, our tests regarding repository discovery break due to not being able to find the repositories anymore. It turns out that these errors occur when the schroot is configured to use an overlayfs on the directory structures. The reason for this failure is that we usually refrain from discovering repositories across devices. But unfortunately, overlayfs does not have consistent device identifiers for all its files but will instead use the device number of the filesystem the file stems from. So whenever we cross boundaries between the upper and lower layer of the overlay, we will fail to properly detect the repository and bail out. This commit fixes the issue by enabling cross-device discovery in our tests. While it would be preferable to have this turned off, it probably won't do much harm anyway as we set up our tests in a temporary location outside of the parent repository.
a7aa73a5	2017-05-02T10:02:36	worktree: introduce git_worktree_add options The `git_worktree_add` function currently accepts only a path and name for the new work tree. As we may want to expand these parameters in future versions without adding additional parameters to the function for every option, this commit introduces our typical pattern of an options struct. Right now, this structure is still empty, which will change with the next commit.
1dc89aab	2017-05-01T21:34:21	object validation: free some memleaks
13c1bf07	2017-05-01T16:17:48	Merge pull request #4197 from pks-t/pks/verify-object-hashes Verify object hashes
5700ee9c	2017-05-01T16:10:50	Merge pull request #4216 from pks-t/pks/debian-test-failures Debian HTTPS feature test failure
35079f50	2017-04-21T07:31:56	odb: add option to turn off hash verification Verifying hashsums of objects we are reading from the ODB may be costly as we have to perform an additional hashsum calculation on the object. Especially when reading large objects, the penalty can be as high as 35%, as can be seen when executing the equivalent of `git cat-file` with and without verification enabled. To mitigate for this, we add a global option for libgit2 which enables the developer to turn off the verification, e.g. when he can be reasonably sure that the objects on disk won't be corrupted.
28a0741f	2017-04-10T09:30:08	odb: verify object hashes The upstream git.git project verifies objects when looking them up from disk. This avoids scenarios where objects have somehow become corrupt on disk, e.g. due to hardware failures or bit flips. While our mantra is usually to follow upstream behavior, we do not do so in this case, as we never check hashes of objects we have just read from disk. To fix this, we create a new error class `GIT_EMISMATCH` which denotes that we have looked up an object with a hashsum mismatch. `odb_read_1` will then, after having read the object from its backend, hash the object and compare the resulting hash to the expected hash. If hashes do not match, it will return an error. This obviously introduces another computation of checksums and could potentially impact performance. Note though that we usually perform I/O operations directly before doing this computation, and as such the actual overhead should be drowned out by I/O. Running our test suite seems to confirm this guess. On a Linux system with best-of-five timings, we had 21.592s with the check enabled and 21.590s with the ckeck disabled. Note though that our test suite mostly contains very small blobs only. It is expected that repositories with bigger blobs may notice an increased hit by this check. In addition to a new test, we also had to change the odb::backend::nonrefreshing test suite, which now triggers a hashsum mismatch when looking up the commit "deadbeef...". This is expected, as the fake backend allocated inside of the test will return an empty object for the OID "deadbeef...", which will obviously not hash back to "deadbeef..." again. We can simply adjust the hash to equal the hash of the empty object here to fix this test.
d59dabe5	2017-04-10T09:00:51	tests: object: test looking up corrupted objects We currently have no tests which check whether we fail reading corrupted objects. Add one which modifies contents of an object stored on disk and then tries to read the object.
86c03552	2017-04-10T09:27:04	tests: object: create sandbox The object::lookup tests do use the "testrepo.git" repository in a read-only way, so we do not set up the repository as a sandbox but simply open it. But in a future commit, we will want to test looking up objects which are corrupted in some way, which requires us to modify the on-disk data. Doing this in a repository without creating the sandbox will modify contents of our libgit2 repository, though. Create the repository in a sandbox to avoid this.
e29e8029	2017-04-10T10:31:22	tests: odb: make hash of fake backend configurable In the odb::backend::nonrefreshing test suite, we set up a fake backend so that we are able to determine if backend functions are called correctly. During the setup, we also parse an OID which is later on used to read out the pseudo-object. While this procedure works right now, it will create problems later when we implement hash verification for looked up objects. The current OID ("deadbeef") will not match the hash of contents we give back to the ODB layer and thus cannot be verified. Make the hash configurable so that we can simply switch the returned for single tests.
7df580fa	2017-04-28T11:58:49	Merge pull request #4191 from pks-t/pks/wt-ref-renames Branch renames with worktrees
2a7086fa	2017-04-25T13:23:04	tests: config: verify functionality with read-only backends
417319cc	2017-04-25T10:14:37	tests: core::features: only check for HTTPS if it is supported
a4de1ae3	2017-04-25T10:14:19	cmake: define GIT_HTTPS when HTTPS is supported
13c275ab	2017-04-21T07:49:08	tests: threads::diff: fix warning for unused variable The threads::diff test suite has a static variable `_retries`, which is used on Windows platforms only. As it is unused on other systems, the compiler throws a warning there. Fix the warning by wrapping the declaration in an ifdef.
8d89e409	2017-04-17T17:19:03	Merge pull request #4192 from libgit2/ethomson/win32_posix Refactor some of the win32 POSIX emulation
78b8f039	2017-02-15T14:00:38	tests: fix indentation in checkout::head::with_index_only_tree
cf07db2f	2017-04-07T16:05:10	filter: only close filter if it's been initialized correctly In the function `git_filter_list_stream_data`, we initialize, write and subesquently close the stream which should receive content processed by the filter. While we skip writing to the stream if its initialization failed, we still try to close it unconditionally -- even if the initialization failed, where the stream might not be set at all, leading us to segfault. Semantics in this code is not really clear. The function handling the same logic for files instead of data seems to do the right thing here in only closing the stream when initialization succeeded. When stepping back a bit, this is only reasonable: if a stream cannot be initialized, the caller would not expect it to be closed again. So actually, both callers of `stream_list_init` fail to do so. The data streaming function will always close the stream and the file streaming function will not close the stream if writing to it has failed. The fix is thus two-fold: - callers of `stream_list_init` now close the stream iff it has been initialized - `stream_list_init` now closes the lastly initialized stream if the current stream in the chain failed to initialize Add a test which segfaulted previous to these changes.
2a485dab	2017-04-04T18:55:57	refs: update worktree HEADs when renaming branches Whenever we rename a branch, we update the repository's symbolic HEAD reference if it currently points to the branch that is to be renamed. But with the introduction of worktrees, we also have to iterate over all HEADs of linked worktrees to adjust them. Do so.
60297256	2017-04-04T16:12:27	tests: worktree::refs: convert spaces to tabs
48f09c6c	2017-04-05T11:59:03	win32: only set `git_win32__retries` where it exists
89d403cc	2017-04-05T09:50:12	win32: enable `p_utimes` for readonly files Instead of failing to set the timestamp of a read-only file (like any object file), set it writable temporarily to update the timestamp.
7ece9065	2017-04-03T23:07:16	win32: make posix emulation retries configurable POSIX emulation retries should be configurable so that tests can disable them. In particular, maniacally threading tests may end up trying to open locked files and need retries, which will slow continuous integration tests significantly.
e86d02f9	2017-04-03T00:10:47	git_repository_set_head: use remote name in reflog When `git_repository_set_head` is provided a remote reference, update the reflog with the tag name, like we do with a branch. This helps consumers match the semantics of `git checkout remote`.
ed812ee7	2017-03-23T12:03:29	config::include: sanitize homedir Sanitize the home directory to ensure that we do not accidentally locate a file called `~/.nonexistentfile`.
047fe29c	2016-06-20T13:05:48	add failing test to include a missing config file relative to home dir
6ad091dc	2017-03-23T09:33:09	Merge pull request #4176 from libgit2/ethomson/3872 inet_pton: don't assume addr families don't exist
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
983979fa	2017-03-22T19:52:38	inet_pton: don't assume addr families don't exist Address family 5 might exist on some crazy system like Haiku. Use `INT_MAX-1` as an unsupported address family.
ea3bb5c0	2017-03-21T18:12:02	git_repository_set_head: use tag name in reflog When `git_repository_set_head` is provided a tag reference, update the reflog with the tag name, like we do with a branch. This helps consumers match the semantics of `git checkout tag`.
31059923	2017-03-20T12:16:18	Merge pull request #4169 from csware/absolute-symlink
c10ce7c2	2017-03-20T12:11:05	tests: filebuf: test writing to symlink with absolute paths
b0c9bc92	2017-03-15T13:38:54	submodule: resolve URLs relative to main worktree It is possible to specify submodule URLs relative to the repository location. E.g. having a submodule with URL "../submodule" will look for the submodule at "repo/../submodule". With the introduction of worktrees, though, we cannot simply resolve the URL relative to the repository location itself. If the repository for which a URL is to be resolved is a working tree, we have to resolve the URL relative to the parent's repository path. Otherwise, the URL would change depending on where the working tree is located. Fix this by special-casing when we have a working tree while getting the URL base.
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.
8f154be3	2017-03-17T08:13:59	worktree: write resolved paths into link files The three link files "worktree/.git", ".git/worktrees/<name>/commondir" and ".git/worktrees/<name>/gitdir" should always contain absolute and resolved paths. Adjust the logic creating new worktrees to first use `git_path_prettify_dir` before writing out these files, so that paths are resolved first.
20a368e2	2017-03-15T15:29:29	worktree: parent path should point to the working dir The working tree's parent path should not point to the parent's gitdir, but to the parent's working directory. Pointing to the gitdir would not make any sense, as the parent's working directory is actually equal to both repository's common directory. Fix the issue.
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.
f3c30686	2017-03-15T15:04:24	tests: worktree: use joinpath instead of printf to join paths
fdb3e24a	2017-03-15T14:23:59	tests: worktree: unify init/cleanup in open tests
548e5bdf	2017-03-15T12:28:05	tests: worktree: unify init/cleanup in submodule tests
aa593a65	2017-03-15T12:01:02	tests: worktree: move submodule tests into own suite
c0eba379	2017-03-14T11:01:19	diff_parse: correctly set options for parsed diffs The function `diff_parsed_alloc` allocates and initializes a `git_diff_parsed` structure. This structure also contains diff options. While we initialize its flags, we fail to do a real initialization of its values. This bites us when we want to actually use the generated diff as we do not se the option's version field, which is required to operate correctly. Fix the issue by executing `git_diff_init_options` on the embedded struct.
ad5a909c	2017-03-14T09:39:37	patch_parse: fix parsing minimal trailing diff line In a diff, the shortest possible hunk with a modification (that is, no deletion) results from a file with only one line with a single character which is removed. Thus the following hunk @@ -1 +1 @@ -a + is the shortest valid hunk modifying a line. The function parsing the hunk body though assumes that there must always be at least 4 bytes present to make up a valid hunk, which is obviously wrong in this case. The absolute minimum number of bytes required for a modification is actually 2 bytes, that is the "+" and the following newline. Note: if there is no trailing newline, the assumption will not be offended as the diff will have a line "\ No trailing newline" at its end. This patch fixes the issue by lowering the amount of bytes required.
ace3508f	2017-03-14T10:37:47	patch_generate: fix `git_diff_foreach` only working with generated diffs The current logic of `git_diff_foreach` makes the assumption that all diffs passed in are actually derived from generated diffs. With these assumptions we try to derive the actual diff by inspecting either the working directory files or blobs of a repository. This obviously cannot work for diffs parsed from a file, where we do not necessarily have a repository at hand. Since the introduced split of parsed and generated patches, there are multiple functions which help us to handle patches generically, being indifferent from where they stem from. Use these functions and remove the old logic specific to generated patches. This allows re-using the same code for invoking the callbacks on the deltas.
53454be8	2017-03-11T19:52:05	Merge pull request #4157 from adamniedzielski/4099-git-sort-time-uninteresting Skip uninteresting commits in revwalk timesort iterator

e0568621

2017-07-19T13:55:55

Merge pull request #4250 from pks-t/pks/config-file-iteration Configuration file fixes with includes

a94a5402

2017-07-19T13:28:32

Merge pull request #4272 from pks-t/pks/patch-id Patch ID calculation

1b329089

2017-05-31T22:27:19

config_file: refuse modifying included variables Modifying variables pulled in by an included file currently succeeds, but it doesn't actually do what one would expect, as refreshing the configuration will cause the values to reappear. As we are currently not really able to support this use case, we will instead just return an error for deleting and setting variables which were included via an include.

28c2cc3d

2017-05-31T16:41:44

config_file: move reader into `config_read` only Right now, we have multiple call sites which initialize a `reader` structure. As the structure is only actually used inside of `config_read`, we can instead just move the reader inside of the `config_read` function. Instead, we can just pass in the configuration file into `config_read`, which eases code readability.

6f7aab0c

2017-06-06T09:45:11

tests: config::include: use init and cleanup functions

83bcd3a1

2017-05-31T22:45:25

config_file: refresh all files if includes were modified Currently, we only re-parse the top-level configuration file when it has changed itself. This can cause problems when an include is changed, as we were not updating all values correctly. Instead of conditionally reparsing only refreshed files, the logic becomes much clearer and easier to follow if we always re-parse the top-level configuration file when either the file itself or one of its included configuration files has changed on disk. This commit implements this logic. Note that this might impact performance in some cases, as we need to re-read all configuration files whenever any of the included files changed. It could increase performance to just re-parse include files which have actually changed, but this would compromise maintainability of the code without much gain. The only case where we will gain anything is when we actually use includes and when only these includes are updated, which will probably be quite an unusual scenario to actually be worthwhile to optimize.

1f7af277

2017-07-05T11:52:47

tests: config: fix missing declaration causing error On systems where we pull in our distributed version of the regex library, all tests in config::readonly fail. This error is actually quite interesting: the test suite is unable to find the declaration of `git_path_exists` and assumes it has a signature of `int git_path_exists(const char *)`. But actually, it has a `bool` return value. Due to this confusion, some wrong conversion is done by the compiler and the `cl_assert(!git_path_exists("file"))` checks erroneously fail, even when the function does in fact return the correct value. The error is actually introduced by 56893bb9a (cmake: consistently use TARGET_INCLUDE_DIRECTORIES if available, 2017-06-28), unfortunately introduced by myself. Due to the delayed addition of include directories, we will now find the "config.h" header inside of the "deps/regex" directory instead of inside the "src/" directory, where it should be. As such, we are missing definitions for the `git_config_file__ondisk` and `git_path_exists` symbols. The correct fix here would be to fix the order in which include search directories are added. But due to the current restructuring of CMakeBuild.txt, I'm refraining from doing so and delay the proper fix a bit. Instead, we paper over the issue by explicitly including "path.h" to fix its prototype. This ignores the issue that `git_config_file__ondisk` is undeclared, as its signature is correctly identified by the compiler.

89a34828

2017-06-16T13:34:43

diff: implement function to calculate patch ID The upstream git project provides the ability to calculate a so-called patch ID. Quoting from git-patch-id(1): A "patch ID" is nothing but a sum of SHA-1 of the file diffs associated with a patch, with whitespace and line numbers ignored." Patch IDs can be used to identify two patches which are probably the same thing, e.g. when a patch has been cherry-picked to another branch. This commit implements a new function `git_diff_patchid`, which gets a patch and derives an OID from the diff. Note the different terminology here: a patch in libgit2 are the differences in a single file and a diff can contain multiple patches for different files. The implementation matches the upstream implementation and should derive the same OID for the same diff. In fact, some code has been directly derived from the upstream implementation. The upstream implementation has two different modes to calculate patch IDs, which is the stable and unstable mode. The old way of calculating the patch IDs was unstable in a sense that a different ordering the diffs was leading to different results. This oversight was fixed in git 1.9, but as git tries hard to never break existing workflows, the old and unstable way is still default. The newer and stable way does not care for ordering of the diff hunks, and in fact it is the mode that should probably be used today. So right now, we only implement the stable way of generating the patch ID.

b6ed67c2

2017-05-10T12:54:14

tests: refs::crashes: create sandbox for creating symref The test `refs::crashes::double_free` operates on our in-source "testrepo.git" repository without creating a copy first. As the test will try to create a new symbolic reference, this will fail when we want to do a pure out-of-tree build with a read-only source tree. Fix the issue by creating a sandbox first.

6ee7d37a

2017-05-10T12:51:06

tests: index::tests: create sandboxed repo for locking The test `index::tests::can_lock_index` operates on the "testrepo.git" repository located inside of our source tree. While this is okay for tests which do read-only operations on these resouces, this specific test tries to lock the index by creating a lock. This will obviously fail on out-of-tree builds with read-only source trees. Fix the issue by creating a sandbox first.

8d22bcea

2017-05-10T12:21:53

generate.py: generate clar cache in binary directory The source directory should usually not be touched when using out-of-tree builds. But next to the previously fixed "clar.suite" file, we are also writing the ".clarcache" into the project's source tree, breaking the builds. Fix this by also honoring the output directory for the ".clarcache" file.

9e240bd2

2017-05-10T12:02:03

generate.py: enable overriding path of generated clar.suite The generate.py script will currently always write the generated clar.suite file into the scanned directory, breaking out-of-tree builds with read-only source directories. Fix this issue by adding another option to allow overriding the output path of the generated file.

0a513a94

2017-05-10T11:46:00

generate.py: disallow generating test suites for multiple paths Our generate.py script is used to extract and write test suite declarations into the clar.suite file. As is, the script accepts multiple directories on the command line and will generate this file for each of these directories. The generate.py script will always write the clar.suite file into the directory which is about to be scanned. This actually breaks out-of-tree builds with libgit2, as the file will be generated in the source tree instead of in the build tree. This is noticed especially in the case where the source tree is mounted read-only, rendering us unable to build unit tests. Due to us accepting multiple paths which are to be scanned, it is not trivial to fix though. The first solution which comes into mind would be to re-create the directory hierarchy at a given output path or use unique names for the clar.suite files, but this is rather cumbersome and magical. The second and cleaner solution would be to fold all directories into a single clar.suite file, but this would probably break some use-cases. Seeing that we do not ever pass multiple directories to generate.py, we will now simply retire support for this. This allows us to later on introduce an additional option to specify the path where the clar.suite file will be generated at, defaulting to "clar.suite" inside of the scanned directory.

62c44c49

2017-06-21T12:25:26

Merge pull request #4211 from pks-t/pks/trusty travis: upgrade container to Ubuntu 14.04

c2c95ad0

2017-04-26T13:16:18

tests: online::clone: use URL of test server All our tests running against a local SSH server usually read the server's URL from environment variables. But online::clone::ssh_cert test fails to do so and instead always connects to "ssh://localhost/foo". This assumption breaks whenever the SSH server is not running on the standard port, e.g. when it is running as a user. Fix the issue by using the URL provided by the environment.

8e912e79

2017-06-16T21:05:58

tests: try to init with empty template path

8296da5f

2017-06-14T10:49:28

Merge pull request #4267 from mohseenrm/master adding GIT_FILTER_VERSION to GIT_FILTER_INIT as part of convention

a78441bc

2017-06-13T11:05:40

Adding git_filter_init for initializing `git_filter` struct + unit test

a180e7d9

2017-06-13T11:10:19

tests: odb: add more low-level backend tests Introduce a new test suite "odb::backend::simple", which utilizes the fake backend to exercise the ODB abstraction layer. While such tests already exist for the case where multiple backends are put together, no direct testing for functionality with a single backend exist yet.

b2e53f36

2017-06-13T11:39:36

tests: odb: implement `exists_prefix` for the fake backend The fake backend currently implements all reading functions except for the `exists_prefix` one. Implement it to enable further testing of the ODB layer.

983e627d

2017-06-13T11:38:59

tests: odb: use correct OID length The `search_object` function takes the OID length as one of its parameters, where its maximum length is `GIT_OID_HEXSZ`. The `exists` function of the fake backend used `GIT_OID_RAWSZ` though, leading to only the first half of the OID being used when finding the correct object.

c4cbb3b1

2017-06-13T11:38:14

tests: odb: have the fake backend detect ambiguous prefixes In order to be able to test the ODB prefix functions, we need to be able to detect ambiguous prefixes in case multiple objects with the same prefix exist in the fake ODB. Extend `search_object` to detect ambiguous queries and have callers return its error code instead of always returning `GIT_ENOTFOUND`.

95170294

2017-06-13T11:08:28

tests: core: test initialization of `git_proxy_options` Initialization of the `git_proxy_options` structure is never tested anywhere. Include it in our usual initialization test in "core::structinit::compare".

bee423cc

2017-06-13T10:29:23

tests: network: add missing include for `git_repository_new` A newly added test uses the `git_repository_new` function without the corresponding header file being included. While this works due to the compiler deducing the correct function signature, we should obviously just include the function's declaration file.

2ca088bd

2017-06-12T22:47:54

Merge pull request #4265 from pks-t/pks/read-prefix-tests Read prefix tests

fe9a5dd3

2017-06-12T12:00:14

remote: ensure we can create an anon remote on inmemory repo Given a wholly in-memory repository, ensure that we can create an anonymous remote and perform actions on it.

f148258a

2017-06-12T16:19:45

tests: odb: add tests with multiple backends Previous to pulling out and extending the fake backend, it was quite cumbersome to write tests for very specific scenarios regarding backends. But as we have made it more generic, it has become much easier to do so. As such, this commit adds multiple tests for scenarios with multiple backends for the ODB. The changes also include a test for a very targeted scenario. When one backend found a matching object via `read_prefix`, but the last backend returns `GIT_ENOTFOUND` and when object hash verification is turned off, we fail to reset the error code to `GIT_OK`. This causes us to segfault later on, when doing a double-free on the returned object.

6e010bb1

2017-06-12T15:43:56

tests: odb: allow passing fake objects to the fake backend Right now, the fake backend is quite restrained in the way how it works: we pass it an OID which it is to return later as well as an error code we want it to return. While this is sufficient for existing tests, we can make the fake backend a little bit more generic in order to allow us testing for additional scenarios. To do so, we change the backend to not accept an error code and OID which it is to return for queries, but instead a simple array of OIDs with their respective blob contents. On each query, the fake backend simply iterates through this array and returns the first matching object.

369cb45f

2017-06-12T15:21:58

tests: do not reuse OID from backend In order to make the fake backend more useful, we want to enable it holding multiple object references. To do so, we need to decouple it from the single fake OID it currently holds, which we simply move up into the calling tests.

2add34d0

2017-06-12T14:53:46

tests: odb: move fake backend into its own file The fake backend used by the test suite `odb::backend::nonrefreshing` is useful to have some low-level tests for the ODB layer. As such, we move the implementation into its own `backend_helpers` module.

6f960b55

2017-06-11T10:37:46

Merge pull request #4088 from chescock/packfile-name-using-complete-hash Ensure packfiles with different contents have different names

d2c4f764

2017-06-11T09:54:04

Merge pull request #4260 from libgit2/ethomson/forced_checkout_2 Update to forced checkout and untracked files

0ef405b3

2017-02-15T14:05:10

checkout: do not delete directories with untracked entries If the `GIT_CHECKOUT_FORCE` flag is given to any of the `git_checkout` invocations, we remove files which were previously staged. But while doing so, we unfortunately also remove unstaged files in a directory which contains at least one staged file, resulting in potential data loss. This commit adds two tests to verify behavior.

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.

92d3ea4e

2017-05-19T13:04:32

tests: index::version: improve write test for index v4 The current write test does not trigger some edge-cases in the index version 4 path compression code. Rewrite the test to start off the an empty standard repository, creating index entries with interesting paths itself. This allows for more fine-grained control over checked paths. Furthermore, we now also verify that entry paths are actually reconstructed correctly.

8fe33538

2017-05-19T12:45:48

tests: index::version: verify we write compressed index entries While we do have a test which checks whether a written index of version 4 has the correct version set, we do not check whether this actually enables path compression for index entries. This commit adds a new test by adding a number of index entries with equal path prefixes to the index and subsequently flushing that to disk. With suffix compression enabled by index version 4, only the last few bytes of these paths will actually have to be written to the index, saving a lot of disk space. For the test, differences are about an order of magnitude, allowing us to easily verify without taking a deeper look at actual on-disk contents.

82368b1b

2017-05-12T10:04:42

tests: index::version: add test to read index version v4 While we have a simple test to determine whether we can write an index of version 4, we never verified that we are able to read this kind of index (and in fact, we were not able to do so). Add a new repository which has an index of version 4. This repository is then read from a new test.

fea0c81e

2017-05-12T09:09:07

tests: index::version: move up cleanup function The init and cleanup functions for test suites are usually prepended to our actual tests. The index::version test suite does not adhere to this stile. Fix this.

8a5e7aae

2017-05-22T12:53:44

varint: fix computation for remaining buffer space When encoding varints to a buffer, we want to remain sure that the required buffer space does not exceed what is actually available. Our current check does not do the right thing, though, in that it does not honor that our `pos` variable counts the position down instead of up. As such, we will require too much memory for small varints and not enough memory for big varints. Fix the issue by correctly calculating the required size as `(sizeof(varint) - pos)`. Add a test which failed before.

dd0aa811

2017-06-04T22:46:07

Merge branch 'pr/4228'

82e929a8

2017-06-04T19:35:39

Merge pull request #4239 from roblg/toplevel-dir-ignore-fix Fix issue with directory glob ignore in subdirectories

04de614b

2017-06-04T19:03:07

Merge pull request #4243 from pks-t/pks/submodule-workdir Submodule working directory

a1023a43

2017-05-20T17:18:07

Merge pull request #4179 from libgit2/ethomson/expand_tilde Introduce home directory expansion function for config files, attribute files

e694e4e9

2017-05-20T14:17:36

Merge pull request #4174 from libgit2/ethomson/set_head_to_tag git_repository_set_head: use tag name in reflog

119bdd86

2017-05-20T14:13:27

Merge pull request #4231 from wabain/open-revrange revparse: support open-ended ranges

c0e54155

2017-01-11T10:39:59

indexer: name pack files after trailer hash Upstream git.git has changed the way how packfiles are named. Previously, they were using a hash of the contained object's OIDs, which has then been changed to use the hash of the complete packfile instead. See 1190a1acf (pack-objects: name pack files after trailer hash, 2013-12-05) in the git.git repository for more information on this change. This commit changes our logic to match the behavior of core git.

2696c5c3

2017-05-19T09:21:17

repository: make check if repo is a worktree more strict To determine if a repository is a worktree or not, we currently check for the existence of a "gitdir" file inside of the repository's gitdir. While this is sufficient for non-broken repositories, we have at least one case of a subtly broken repository where there exists a gitdir file inside of a gitmodule. This will cause us to misidentify the submodule as a worktree. While this is not really a fault of ours, we can do better here by observing that a repository can only ever be a worktree iff its common directory and dotgit directory are different. This allows us to make our check whether a repo is a worktree or not more strict by doing a simple string comparison of these two directories. This will also allow us to do the right thing in the above case of a broken repository, as for submodules these directories will be the same. At the same time, this allows us to skip the `stat` check for the "gitdir" file for most repositories.

c3b8e8b3

2017-05-14T10:28:05

Fix issue with directory glob ignore in subdirectories

e526fbc7

2017-05-17T09:23:06

tests: add test suite for opening submodules

98a5f081

2017-05-03T13:53:13

tests: threads::basic: remove unused function `exit_abruptly`

7d7f6d33

2017-05-03T13:52:55

tests: clone::local: compile UNC functions for Windows only

8b107dc5

2017-05-03T11:20:57

revparse: support open-ended ranges Support '..' and '...' ranges where one side is not specified. The unspecified side defaults to HEAD. Closes #4223

883eeb5f

2017-05-02T12:35:59

worktree: switch over worktree pruning to an opts structure The current signature of `git_worktree_prune` accepts a flags field to alter its behavior. This is not as flexible as we'd like it to be when we want to enable passing additional options in the future. As the function has not been part of any release yet, we are still free to alter its current signature. This commit does so by using our usual pattern of an options structure, which is easily extendable without breaking the API.

8264a30f

2017-05-02T10:11:28

worktree: support creating locked worktrees When creating a new worktree, we do have a potential race with us creating the worktree and another process trying to delete the same worktree as it is being created. As such, the upstream git project has introduced a flag `git worktree add --locked`, which will cause the newly created worktree to be locked immediately after its creation. This mitigates the race condition. We want to be able to mirror the same behavior. As such, a new flag `locked` is added to the options structure of `git_worktree_add` which allows the user to enable this behavior.

ffd264d9

2017-05-03T14:51:23

tests: repo: fix repo discovery tests on overlayfs Debian and Ubuntu often use schroot to build their DEB packages in a controlled environment. Depending on how schroot is configured, our tests regarding repository discovery break due to not being able to find the repositories anymore. It turns out that these errors occur when the schroot is configured to use an overlayfs on the directory structures. The reason for this failure is that we usually refrain from discovering repositories across devices. But unfortunately, overlayfs does not have consistent device identifiers for all its files but will instead use the device number of the filesystem the file stems from. So whenever we cross boundaries between the upper and lower layer of the overlay, we will fail to properly detect the repository and bail out. This commit fixes the issue by enabling cross-device discovery in our tests. While it would be preferable to have this turned off, it probably won't do much harm anyway as we set up our tests in a temporary location outside of the parent repository.

a7aa73a5

2017-05-02T10:02:36

worktree: introduce git_worktree_add options The `git_worktree_add` function currently accepts only a path and name for the new work tree. As we may want to expand these parameters in future versions without adding additional parameters to the function for every option, this commit introduces our typical pattern of an options struct. Right now, this structure is still empty, which will change with the next commit.

1dc89aab

2017-05-01T21:34:21

object validation: free some memleaks

13c1bf07

2017-05-01T16:17:48

Merge pull request #4197 from pks-t/pks/verify-object-hashes Verify object hashes

5700ee9c

2017-05-01T16:10:50

Merge pull request #4216 from pks-t/pks/debian-test-failures Debian HTTPS feature test failure

35079f50

2017-04-21T07:31:56

odb: add option to turn off hash verification Verifying hashsums of objects we are reading from the ODB may be costly as we have to perform an additional hashsum calculation on the object. Especially when reading large objects, the penalty can be as high as 35%, as can be seen when executing the equivalent of `git cat-file` with and without verification enabled. To mitigate for this, we add a global option for libgit2 which enables the developer to turn off the verification, e.g. when he can be reasonably sure that the objects on disk won't be corrupted.

28a0741f

2017-04-10T09:30:08

odb: verify object hashes The upstream git.git project verifies objects when looking them up from disk. This avoids scenarios where objects have somehow become corrupt on disk, e.g. due to hardware failures or bit flips. While our mantra is usually to follow upstream behavior, we do not do so in this case, as we never check hashes of objects we have just read from disk. To fix this, we create a new error class `GIT_EMISMATCH` which denotes that we have looked up an object with a hashsum mismatch. `odb_read_1` will then, after having read the object from its backend, hash the object and compare the resulting hash to the expected hash. If hashes do not match, it will return an error. This obviously introduces another computation of checksums and could potentially impact performance. Note though that we usually perform I/O operations directly before doing this computation, and as such the actual overhead should be drowned out by I/O. Running our test suite seems to confirm this guess. On a Linux system with best-of-five timings, we had 21.592s with the check enabled and 21.590s with the ckeck disabled. Note though that our test suite mostly contains very small blobs only. It is expected that repositories with bigger blobs may notice an increased hit by this check. In addition to a new test, we also had to change the odb::backend::nonrefreshing test suite, which now triggers a hashsum mismatch when looking up the commit "deadbeef...". This is expected, as the fake backend allocated inside of the test will return an empty object for the OID "deadbeef...", which will obviously not hash back to "deadbeef..." again. We can simply adjust the hash to equal the hash of the empty object here to fix this test.

d59dabe5

2017-04-10T09:00:51

tests: object: test looking up corrupted objects We currently have no tests which check whether we fail reading corrupted objects. Add one which modifies contents of an object stored on disk and then tries to read the object.

86c03552

2017-04-10T09:27:04

tests: object: create sandbox The object::lookup tests do use the "testrepo.git" repository in a read-only way, so we do not set up the repository as a sandbox but simply open it. But in a future commit, we will want to test looking up objects which are corrupted in some way, which requires us to modify the on-disk data. Doing this in a repository without creating the sandbox will modify contents of our libgit2 repository, though. Create the repository in a sandbox to avoid this.

e29e8029

2017-04-10T10:31:22

tests: odb: make hash of fake backend configurable In the odb::backend::nonrefreshing test suite, we set up a fake backend so that we are able to determine if backend functions are called correctly. During the setup, we also parse an OID which is later on used to read out the pseudo-object. While this procedure works right now, it will create problems later when we implement hash verification for looked up objects. The current OID ("deadbeef") will not match the hash of contents we give back to the ODB layer and thus cannot be verified. Make the hash configurable so that we can simply switch the returned for single tests.

7df580fa

2017-04-28T11:58:49

Merge pull request #4191 from pks-t/pks/wt-ref-renames Branch renames with worktrees

2a7086fa

2017-04-25T13:23:04

tests: config: verify functionality with read-only backends

417319cc

2017-04-25T10:14:37

tests: core::features: only check for HTTPS if it is supported

a4de1ae3

2017-04-25T10:14:19

cmake: define GIT_HTTPS when HTTPS is supported

13c275ab

2017-04-21T07:49:08

tests: threads::diff: fix warning for unused variable The threads::diff test suite has a static variable `_retries`, which is used on Windows platforms only. As it is unused on other systems, the compiler throws a warning there. Fix the warning by wrapping the declaration in an ifdef.

8d89e409

2017-04-17T17:19:03

Merge pull request #4192 from libgit2/ethomson/win32_posix Refactor some of the win32 POSIX emulation

78b8f039

2017-02-15T14:00:38

tests: fix indentation in checkout::head::with_index_only_tree

cf07db2f

2017-04-07T16:05:10

filter: only close filter if it's been initialized correctly In the function `git_filter_list_stream_data`, we initialize, write and subesquently close the stream which should receive content processed by the filter. While we skip writing to the stream if its initialization failed, we still try to close it unconditionally -- even if the initialization failed, where the stream might not be set at all, leading us to segfault. Semantics in this code is not really clear. The function handling the same logic for files instead of data seems to do the right thing here in only closing the stream when initialization succeeded. When stepping back a bit, this is only reasonable: if a stream cannot be initialized, the caller would not expect it to be closed again. So actually, both callers of `stream_list_init` fail to do so. The data streaming function will always close the stream and the file streaming function will not close the stream if writing to it has failed. The fix is thus two-fold: - callers of `stream_list_init` now close the stream iff it has been initialized - `stream_list_init` now closes the lastly initialized stream if the current stream in the chain failed to initialize Add a test which segfaulted previous to these changes.

2a485dab

2017-04-04T18:55:57

refs: update worktree HEADs when renaming branches Whenever we rename a branch, we update the repository's symbolic HEAD reference if it currently points to the branch that is to be renamed. But with the introduction of worktrees, we also have to iterate over all HEADs of linked worktrees to adjust them. Do so.

60297256

2017-04-04T16:12:27

tests: worktree::refs: convert spaces to tabs

48f09c6c

2017-04-05T11:59:03

win32: only set `git_win32__retries` where it exists

89d403cc

2017-04-05T09:50:12

win32: enable `p_utimes` for readonly files Instead of failing to set the timestamp of a read-only file (like any object file), set it writable temporarily to update the timestamp.

7ece9065

2017-04-03T23:07:16

win32: make posix emulation retries configurable POSIX emulation retries should be configurable so that tests can disable them. In particular, maniacally threading tests may end up trying to open locked files and need retries, which will slow continuous integration tests significantly.

e86d02f9

2017-04-03T00:10:47

git_repository_set_head: use remote name in reflog When `git_repository_set_head` is provided a remote reference, update the reflog with the tag name, like we do with a branch. This helps consumers match the semantics of `git checkout remote`.

ed812ee7

2017-03-23T12:03:29

config::include: sanitize homedir Sanitize the home directory to ensure that we do not accidentally locate a file called `~/.nonexistentfile`.

047fe29c

2016-06-20T13:05:48

add failing test to include a missing config file relative to home dir

6ad091dc

2017-03-23T09:33:09

Merge pull request #4176 from libgit2/ethomson/3872 inet_pton: don't assume addr families don't exist

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

983979fa

2017-03-22T19:52:38

inet_pton: don't assume addr families don't exist Address family 5 might exist on some crazy system like Haiku. Use `INT_MAX-1` as an unsupported address family.

ea3bb5c0

2017-03-21T18:12:02

git_repository_set_head: use tag name in reflog When `git_repository_set_head` is provided a tag reference, update the reflog with the tag name, like we do with a branch. This helps consumers match the semantics of `git checkout tag`.

31059923

2017-03-20T12:16:18

Merge pull request #4169 from csware/absolute-symlink

c10ce7c2

2017-03-20T12:11:05

tests: filebuf: test writing to symlink with absolute paths

b0c9bc92

2017-03-15T13:38:54

submodule: resolve URLs relative to main worktree It is possible to specify submodule URLs relative to the repository location. E.g. having a submodule with URL "../submodule" will look for the submodule at "repo/../submodule". With the introduction of worktrees, though, we cannot simply resolve the URL relative to the repository location itself. If the repository for which a URL is to be resolved is a working tree, we have to resolve the URL relative to the parent's repository path. Otherwise, the URL would change depending on where the working tree is located. Fix this by special-casing when we have a working tree while getting the URL base.

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.

8f154be3

2017-03-17T08:13:59

worktree: write resolved paths into link files The three link files "worktree/.git", ".git/worktrees/<name>/commondir" and ".git/worktrees/<name>/gitdir" should always contain absolute and resolved paths. Adjust the logic creating new worktrees to first use `git_path_prettify_dir` before writing out these files, so that paths are resolved first.

20a368e2

2017-03-15T15:29:29

worktree: parent path should point to the working dir The working tree's parent path should not point to the parent's gitdir, but to the parent's working directory. Pointing to the gitdir would not make any sense, as the parent's working directory is actually equal to both repository's common directory. Fix the issue.

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.

f3c30686

2017-03-15T15:04:24

tests: worktree: use joinpath instead of printf to join paths

fdb3e24a

2017-03-15T14:23:59

tests: worktree: unify init/cleanup in open tests

548e5bdf

2017-03-15T12:28:05

tests: worktree: unify init/cleanup in submodule tests

aa593a65

2017-03-15T12:01:02

tests: worktree: move submodule tests into own suite

c0eba379

2017-03-14T11:01:19

diff_parse: correctly set options for parsed diffs The function `diff_parsed_alloc` allocates and initializes a `git_diff_parsed` structure. This structure also contains diff options. While we initialize its flags, we fail to do a real initialization of its values. This bites us when we want to actually use the generated diff as we do not se the option's version field, which is required to operate correctly. Fix the issue by executing `git_diff_init_options` on the embedded struct.

ad5a909c

2017-03-14T09:39:37

patch_parse: fix parsing minimal trailing diff line In a diff, the shortest possible hunk with a modification (that is, no deletion) results from a file with only one line with a single character which is removed. Thus the following hunk @@ -1 +1 @@ -a + is the shortest valid hunk modifying a line. The function parsing the hunk body though assumes that there must always be at least 4 bytes present to make up a valid hunk, which is obviously wrong in this case. The absolute minimum number of bytes required for a modification is actually 2 bytes, that is the "+" and the following newline. Note: if there is no trailing newline, the assumption will not be offended as the diff will have a line "\ No trailing newline" at its end. This patch fixes the issue by lowering the amount of bytes required.

ace3508f

2017-03-14T10:37:47

patch_generate: fix `git_diff_foreach` only working with generated diffs The current logic of `git_diff_foreach` makes the assumption that all diffs passed in are actually derived from generated diffs. With these assumptions we try to derive the actual diff by inspecting either the working directory files or blobs of a repository. This obviously cannot work for diffs parsed from a file, where we do not necessarily have a repository at hand. Since the introduced split of parsed and generated patches, there are multiple functions which help us to handle patches generically, being indifferent from where they stem from. Use these functions and remove the old logic specific to generated patches. This allows re-using the same code for invoking the callbacks on the deltas.

53454be8

2017-03-11T19:52:05

Merge pull request #4157 from adamniedzielski/4099-git-sort-time-uninteresting Skip uninteresting commits in revwalk timesort iterator

thodg/libgit2/tests

tests

Log