kmx git

Commit	Date	Message
d9007dc8	2018-04-03T11:36:27	Merge pull request #4607 from Sp1l/private/fix-libressl-2.7 Fix build with LibreSSL 2.7
c42261a3	2018-04-03T09:38:38	Merge pull request #4603 from pks-t/pks/appveyor-winhttp-workaround appveyor: workaround for intermittent test failures
b5e0cfa7	2018-04-03T09:32:33	Merge pull request #4601 from bgermann/master sha1dc: update to fix errors with endianess
7490d449	2018-04-02T20:00:07	Fix build with LibreSSL 2.7 LibreSSL 2.7 adds OpenSSL 1.1 API Signed-off-by: Bernard Spil <brnrd@FreeBSD.org>
dc27772c	2018-03-30T13:12:26	Merge pull request #4378 from cjhoward92/fix/submodule-add-check-index submodule: check index for path and prefix before adding submodule
fbe52fa3	2018-03-29T10:18:51	util: fix missing headers for MinGW environments There are multiple references to undefined functions in the Microsoft builds. Add headers to make them known.
b6276ae0	2018-03-29T09:15:48	odb: mempack: fix leaking objects when freeing mempacks When a ODB mempack gets free'd, we take no measures at all to free its contents, most notably the objects added to the database, resulting in a memory leak. Call `git_mempack_reset` previous to freeing the ODB structures themselves, which takes care of releasing all associated data structures.
c9e5ba09	2018-03-28T17:37:39	sha1dc: update to fix errors with endianess This updates the version of SHA1DC to c3e1304ea3.
69a282da	2018-03-28T06:48:55	submodule: add more robust error handling when a submodule path is found on add
c07abd65	2018-03-27T07:37:34	submodule: add better error handling to is_path_occupied
b282ca79	2018-01-06T10:57:32	submodule: change can_add_submodule to is_path_occupied
ef9a7749	2017-11-19T20:59:59	submodule: update index check to check path before directory and fix tests
9371149f	2017-10-20T14:24:01	submodule: fix styling errors
ad1c4350	2017-10-16T15:30:47	submodule: check index for prefix before adding submodule submodule: check path and prefix before adding submodule submodule: fix test errors
cdd0bc2f	2018-03-26T18:44:13	checkout: change default strategy to SAFE As per #4200, our default is quite surprising to users that expect checkout to just "do the thing".
a52b4c51	2018-03-23T09:59:46	odb: fix writing to fake write streams In commit 7ec7aa4a7 (odb: assert on logic errors when writing objects, 2018-02-01), the check for whether we are trying to overflowing the fake stream buffer was changed from returning an error to raising an assert. The conversion forgot though that the logic around `assert`s are basically inverted. Previously, if the statement stream->written + len > steram->size evaluated to true, we would return a `-1`. Now we are asserting that this statement is true, and in case it is not we will raise an error. So the conversion to the `assert` in fact changed the behaviour to the complete opposite intention. Fix the assert by inverting its condition again and add a regression test.
0e4f3d9d	2018-03-03T21:47:22	gitno_extract_url_parts: decode hostnames RFC 3986 says that hostnames can be percent encoded. Percent decode hostnames in our URLs.
05551ca0	2018-03-03T20:14:54	Remove now unnecessary `gitno_unescape`
60e7848e	2018-03-03T20:13:30	gitno_extract_url_parts: use `git_buf`s Now that we can decode percent-encoded strings as part of `git_buf`s, use that decoder in `gitno_extract_url_parts`.
6f577906	2018-03-03T20:09:09	ssh urls: use `git_buf_decode_percent` Use `git_buf_decode_percent` so that we can avoid allocating a temporary buffer.
8070a357	2018-03-03T18:47:35	Introduce `git_buf_decode_percent` Introduce a function to take a percent-encoded string (URI encoded, described by RFC 1738) and decode it into a `git_buf`.
16210877	2018-02-28T12:59:47	Unescape repo before constructing ssh request
8a2cdbd3	2018-02-28T12:58:58	Rename unescape and make non-static
3db1af1f	2018-03-08T12:36:46	index: error out on unreasonable prefix-compressed path lengths When computing the complete path length from the encoded prefix-compressed path, we end up just allocating the complete path without ever checking what the encoded path length actually is. This can easily lead to a denial of service by just encoding an unreasonable long path name inside of the index. Git already enforces a maximum path length of 4096 bytes. As we also have that enforcement ready in some places, just make sure that the resulting path is smaller than GIT_PATH_MAX. Reported-by: Krishna Ram Prakash R <krp@gtux.in> Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
3207ddb0	2018-03-08T12:00:27	index: fix out-of-bounds read with invalid index entry prefix length The index format in version 4 has prefix-compressed entries, where every index entry can compress its path by using a path prefix of the previous entry. Since implmenting support for this index format version in commit 5625d86b9 (index: support index v4, 2016-05-17), though, we do not correctly verify that the prefix length that we want to reuse is actually smaller or equal to the amount of characters than the length of the previous index entry's path. This can lead to a an integer underflow and subsequently to an out-of-bounds read. Fix this by verifying that the prefix is actually smaller than the previous entry's path length. Reported-by: Krishna Ram Prakash R <krp@gtux.in> Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
58a6fe94	2018-03-08T11:49:19	index: convert `read_entry` to return entry size via an out-param The function `read_entry` does not conform to our usual coding style of returning stuff via the out parameter and to use the return value for reporting errors. Due to most of our code conforming to that pattern, it has become quite natural for us to actually return `-1` in case there is any error, which has also slipped in with commit 5625d86b9 (index: support index v4, 2016-05-17). As the function returns an `size_t` only, though, the return value is wrapped around, causing the caller of `read_tree` to continue with an invalid index entry. Ultimately, this can lead to a double-free. Improve code and fix the bug by converting the function to return the index entry size via an out parameter and only using the return value to indicate errors. Reported-by: Krishna Ram Prakash R <krp@gtux.in> Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
53e692af	2018-03-02T12:49:54	worktree: rename parameter creason to reason
12356076	2018-03-02T12:41:04	worktree: lock reason should be const
8a8ea1db	2018-02-28T18:14:52	Merge pull request #4552 from libgit2/cmn/config-header-common Cast less blindly between configuration objects
e8e490b2	2018-02-28T17:01:47	Merge pull request #4554 from pks-t/pks/curl-init curl: initialize and cleanup global curl state
9cd0c6f1	2018-02-28T16:01:16	config: return an error if config_refresh is called on a snapshot Instead of treating it as a no-op, treat it as a programming error and return the same kind of error as if you called to set or delete variables on a snapshot.
2022b004	2018-02-28T12:06:59	curl: explicitly initialize and cleanup global curl state Our curl-based streams make use of the easy curl interface. This interface automatically initializes and de-initializes the global curl state by calling out to `curl_global_init` and `curl_global_cleanup`. Thus, all global state will be repeatedly re-initialized when creating multiple curl streams in succession. Despite being inefficient, this is not thread-safe due to `curl_global_init` being not thread-safe itself. Thus a multi-threaded programing handling multiple curl streams at the same time is inherently racy. Fix the issue by globally initializing and cleaning up curl's state.
a33deeb4	2018-02-28T12:20:23	win32: strncmp -> git__strncmp The win32 C library is compiled cdecl, however when configured with `STDCALL=ON`, our functions (and function pointers) will use the stdcall calling convention. You cannot set a `__stdcall` function pointer to a `__cdecl` function, so it's easier to just use our `git__strncmp` instead of sorting that mess out.
2424e64c	2018-02-28T12:06:02	config: harden our use of the backend objects a bit When we create an iterator we don't actually know that we have a live config object and we must instead only rely on the header. We fixed it to use this in a previous commit, but this makes it harder to misuse by converting to use the header object in the typecast. We also guard inside the `config_refresh` function against being given a snapshot (although callers right now do check).
1785de4e	2018-02-28T11:46:17	config: move the level field into the header We use it in a few places where we might have a full object or a snapshot so move it to where we can actually access it.
c1524b2e	2018-02-28T11:33:11	config: move the repository to the diskfile header We pass this around and when creating a new iterator we need to read the repository pointer. Put it in a common place so we can reach it regardless of whether we got a full object or a snapshot.
c9d59c61	2018-02-27T12:45:21	Merge pull request #4545 from libgit2/ethomson/checkout_filemode Respect core.filemode in checkout
5ecb6220	2018-02-25T15:46:51	winhttp: enable TLS 1.2 on Windows 7 and earlier Versions of Windows prior to Windows 8 do not enable TLS 1.2 by default, though support may exist. Try to enable TLS 1.2 support explicitly on connections. This request may fail if the operating system does not have TLS 1.2 support - the initial release of Vista lacks TLS 1.2 support (though it is available as a software update) and XP completely lacks TLS 1.2 support. If this request does fail, the HTTP context is still valid, and still maintains the original protocol support. So we ignore the failure from this operation.
934e6a3b	2018-02-27T11:24:30	winhttp: include constants for TLS 1.1/1.2 support For platforms that do not define `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1` and/or `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2`.
8c8db980	2018-02-27T10:32:29	mingw: update TLS option flags Include the constants for `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1` and `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2` so that they can be used by mingw. This updates both the `deps/winhttp` framework (for classic mingw) and adds the defines for mingw64, which does not use that framework.
c214ba19	2018-02-20T00:35:27	checkout: respect core.filemode when comparing filemodes Fixes #4504
894ccf4b	2018-02-20T16:14:54	Merge pull request #4535 from libgit2/ethomson/checkout_typechange_with_index_and_wd checkout: when examining index (instead of workdir), also examine mode
ce7080a0	2018-02-20T10:38:27	diff_tform: fix rename detection with rewrite/delete pair A rewritten file can either be classified as a modification of its contents or of a delete of the complete file followed by an addition of the new content. This distinction becomes important when we want to detect renames for rewrites. Given a scenario where a file "a" has been deleted and another file "b" has been renamed to "a", this should be detected as a deletion of "a" followed by a rename of "a" -> "b". Thus, splitting of the original rewrite into a delete/add pair is important here. This splitting is represented by a flag we can set at the current delta. While the flag is already being set in case we want to break rewrites, we do not do so in case where the `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` flag is set. This can trigger an assert when we try to match the source and target deltas. Fix the issue by setting the `GIT_DIFF_FLAG__TO_SPLIT` flag at the delta when it is a rename target and `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` is set.
d7fea1e1	2018-02-18T16:10:33	checkout: take mode into account when comparing index to baseline When checking out a file, we determine whether the baseline (what we expect to be in the working directory) actually matches the contents of the working directory. This is safe behavior to prevent us from overwriting changes in the working directory. We look at the index to optimize this test: if we know that the index matches the working directory, then we can simply look at the index data compared to the baseline. We have historically compared the baseline to the index entry by oid. However, we must also compare the mode of the two items to ensure that they are identical. Otherwise, we will refuse to update the working directory for a mode change.
f1ad004c	2018-02-18T22:29:48	Merge pull request #4529 from libgit2/ethomson/index_add_requires_files git_index_add_frombuffer: only accept files/links
5f774dbf	2018-02-11T10:14:13	git_index_add_frombuffer: only accept files/links Ensure that the buffer given to `git_index_add_frombuffer` represents a regular blob, an executable blob, or a link. Explicitly reject commit entries (submodules) - it makes little sense to allow users to add a submodule from a string; there's no possible path to success.
92324d84	2018-02-16T11:28:53	util: clean up header includes While "util.h" declares the macro `git__tolower`, which simply resorts to tolower(3P) on Unix-like systems, the <ctype.h> header is only being included in "util.c". Thus, anybody who has included "util.h" without having <ctype.h> included will fail to compile as soon as the macro is in use. Furthermore, we can clean up additional includes in "util.c" and simply replace them with an include for "common.h".
06b8a40f	2018-02-16T11:29:46	Explicitly mark fallthrough cases with comments A lot of compilers nowadays generate warnings when there are cases in a switch statement which implicitly fall through to the next case. To avoid this warning, the last line in the case that is falling through can have a comment matching a regular expression, where one possible comment body would be `/* fall through */`. An alternative to the comment would be an explicit attribute like e.g. `[[clang::fallthrough]` or `__attribute__ ((fallthrough))`. But GCC only introduced support for such an attribute recently with GCC 7. Thus, and also because the fallthrough comment is supported by most compilers, we settle for using comments instead. One shortcoming of that method is that compilers are very strict about that. Most interestingly, that comment _really_ has to be the last line. In case a closing brace follows the comment, the heuristic will fail.
7c6e9175	2018-02-16T11:11:11	index: shut up warning on uninitialized variable Even though the `entry` variable will always be initialized when `read_entry` returns success and even though we never dereference `entry` in case `read_entry` fails, GCC prints a warning about uninitialized use. Just initialize the pointer to `NULL` in order to shut GCC up.
84f03b3a	2018-02-16T10:48:55	streams: openssl: fix use of uninitialized variable When verifying the server certificate, we do try to make sure that the hostname actually matches the certificate alternative names. In cases where the host is either an IPv4 or IPv6 address, we have to compare the binary representations of the hostname with the declared IP address of the certificate. We only do that comparison in case we were successfully able to parse the hostname as an IP, which would always result in the memory region being initialized. Still, GCC 6.4.0 was complaining about usage of non-initialized memory. Fix the issue by simply asserting that `addr` needs to be initialized. This shuts up the GCC warning.
ee6be190	2018-01-31T08:36:19	http: standardize user-agent addition The winhttp and posix http each need to add the user-agent to their requests. Standardize on a single function to include this so that we do not get the version numbers we're sending out of sync. Assemble the complete user agent in `git_http__user_agent`, returning assembled strings. Co-authored-by: Patrick Steinhardt <ps@pks.im>
178fda8a	2018-02-09T17:55:18	hash: win32: fix missing comma in `giterr_set`
638c6b8c	2018-02-09T17:32:15	odb_loose: only close file descriptor if it was opened successfully
a43bcd2c	2018-02-09T17:31:50	odb: fix memory leaks due to not freeing hash context
9985edb5	2018-02-01T06:32:55	hash: set error messages on failure
619f61a8	2018-02-01T06:22:36	odb: error when we can't create object header Return an error to the caller when we can't create an object header for some reason (printf failure) instead of simply asserting.
7ec7aa4a	2018-02-01T05:54:57	odb: assert on logic errors when writing objects There's no recovery possible if we're so confused or corrupted that we're trying to overwrite our memory. Simply assert.
138e4c2b	2018-02-01T06:35:31	git_odb__hashfd: propagate error on failures
35ed256b	2018-02-01T05:11:05	git_odb__hashobj: provide errors messages on failures Provide error messages on hash failures: assert when given invalid input instead of failing with a user error; provide error messages on program errors.
59d99adc	2018-01-31T09:34:52	odb: check for alloc errors on hardcoded objects It's unlikely that we'll fail to allocate a single byte, but let's check for allocation failures for good measure. Untangle `-1` being a marker of not having found the hardcoded odb object; use that to reflect actual errors.
ef902864	2018-01-31T09:30:51	odb: error when we can't alloc an object At the moment, we're swallowing the allocation failure. We need to return the error to the caller.
0fd0bfe4	2018-02-08T22:51:46	Merge pull request #4450 from libgit2/ethomson/odb_loose_readstream Streaming read support for the loose ODB backend
d749822c	2018-02-08T22:50:58	Merge pull request #4491 from libgit2/ethomson/recursive Recursive merge: reverse the order of merge bases
ba4faf6e	2018-02-08T17:15:33	buf_text: remove `offset` parameter of BOM detection function The function to detect a BOM takes an offset where it shall look for a BOM. No caller uses that, and searching for the BOM in the middle of a buffer seems to be very unlikely, as a BOM should only ever exist at file start. Remove the parameter, as it has already caused confusion due to its weirdness.
2eea5f1c	2018-02-08T10:27:31	config_parse: fix reading files with BOM The function `skip_bom` is being used to detect and skip BOM marks previously to parsing a configuration file. To do so, it simply uses `git_buf_text_detect_bom`. But since the refactoring to use the parser interface in commit 9e66590bd (config_parse: use common parser interface, 2017-07-21), the BOM detection was actually broken. The issue stems from a misunderstanding of `git_buf_text_detect_bom`. It was assumed that its third parameter limits the length of the character sequence that is to be analyzed, while in fact it was an offset at which we want to detect the BOM. Fix the parameter to be `0` instead of the buffer length, as we always want to check the beginning of the configuration file.
848153f3	2018-02-08T10:02:29	config_parse: handle empty lines with CRLF Currently, the configuration parser will fail reading empty lines with just an CRLF-style line ending. Special-case the '\r' character in order to handle it the same as Unix-style line endings. Add tests to spot this regression in the future.
5340ca77	2018-02-08T09:31:51	config_parse: add comment to clarify logic getting next character Upon each line, the configuration parser tries to get either the first non-whitespace character or the first whitespace character, in case there is no non-whitespace character. The logic handling this looks rather odd and doesn't immediately convey this meaning, so add a comment to clarify what happens.
1403c612	2018-01-22T14:44:31	merge: virtual commit should be last argument to merge-base Our virtual commit must be the last argument to merge-base: since our algorithm pushes _both_ parents of the virtual commit, it needs to be the last argument, since merge-base: > Given three commits A, B and C, git merge-base A B C will compute the > merge base between A and a hypothetical commit M We want to calculate the merge base between the actual commit ("two") and the virtual commit ("one") - since one actually pushes its parents to the merge-base calculation, we need to calculate the merge base of "two" and the parents of one.
b924df1e	2018-01-21T18:05:45	merge: reverse merge bases for recursive merge When the commits being merged have multiple merge bases, reverse the order when creating the virtual merge base. This is for compatibility with git's merge-recursive algorithm, and ensures that we build identical trees. Git does this to try to use older merge bases first. Per 8918b0c: > It seems to be the only sane way to do it: when a two-head merge is > done, and the merge-base and one of the two branches agree, the > merge assumes that the other branch has something new. > > If we start creating virtual commits from newer merge-bases, and go > back to older merge-bases, and then merge with newer commits again, > chances are that a patch is lost, _because_ the merge-base and the > head agree on it. Unlikely, yes, but it happened to me.
ed51feb7	2018-01-21T18:01:20	oidarray: introduce git_oidarray__reverse Provide a simple function to reverse an oidarray.
26f5d36d	2018-02-04T10:27:39	Merge pull request #4489 from libgit2/ethomson/conflicts_crlf Conflict markers should match EOL style in conflicting files
8abd514c	2018-02-02T17:37:12	Merge pull request #4499 from pks-t/pks/setuid-config sysdir: do not use environment in setuid case
2553cbe3	2018-02-02T11:33:46	Merge pull request #4512 from libgit2/ethomson/header_guards Consistent header guards
53454b68	2018-02-02T11:31:15	Merge pull request #4510 from pks-t/pks/attr-file-bare-stat attr: avoid stat'ting files for bare repositories
0967459e	2018-01-25T13:11:34	sysdir: do not use environment in setuid case In order to derive the location of some Git directories, we currently use the environment variables $HOME and $XDG_CONFIG_HOME. This might prove to be problematic whenever the binary is run with setuid, that is when the effective user does not equal the real user. In case the environment variables do not get sanitized by the caller, we thus might end up using the real user's configuration when doing stuff as the effective user. The fix is to use the passwd entry's directory instead of $HOME in this situation. As this might break scenarios where the user explicitly sets $HOME to another path, this fix is only applied in case the effective user does not equal the real user.
09df354e	2018-02-01T16:52:43	odb_loose: HEADER_LEN -> MAX_HEADER_LEN `MAX_HEADER_LEN` is a more descriptive constant name.
624614b2	2017-12-19T00:43:49	odb_loose: validate length when checking for zlib content When checking to see if a file has zlib deflate content, make sure that we actually have read at least two bytes before examining the array.
1118ba3e	2017-12-18T23:08:40	odb_loose: `read_header` for packlike loose objects Support `read_header` for "packlike loose objects", which were a temporarily and uncommonly used format loose object format that encodes the header before the zlib deflate data. This will never actually be seen in the wild, but add support for it for completeness and (more importantly) because our corpus of test data has objects in this format, so it's easier to support it than to try to special case it.
4c7a16b7	2017-12-18T15:56:21	odb_loose: read_header should use zstream Make `read_header` use the common zstream implementation. Remove the now unnecessary zlib wrapper in odb_loose.
6155e06b	2017-12-17T18:44:02	zstream: introduce a single chunk reader Introduce `get_output_chunk` that will inflate/deflate all the available input buffer into the output buffer. `get_output` will call `get_output_chunk` in a loop, while other consumers can use it to inflate only a piece of the data.
80dc3946	2017-12-17T16:26:48	odb_loose: packlike loose objects use `git_zstream` Refactor packlike loose object reads to use `git_zstream` for simplification.
7cb5bae7	2017-12-17T11:55:18	odb: loose object streaming for packlike loose objects A "packlike" loose object was a briefly lived loose object format where the type and size were encoded in uncompressed space at the beginning of the file, followed by the compressed object contents. Handle these in a streaming manner as well.
b61846f2	2017-12-17T02:14:29	odb: introduce streaming loose object reader Provide a streaming loose object reader.
97f9a5f0	2017-12-17T01:12:49	odb: provide length and type with streaming read The streaming read functionality should provide the length and the type of the object, like the normal read functionality does.
c74e9271	2017-12-16T22:10:11	odb_loose: stream -> writestream There are two streaming functions; one for reading, one for writing. Disambiguate function names between `stream` and `writestream` to make allowances for a read stream.
abb04caa	2018-02-01T15:55:48	consistent header guards use consistent names for the #include / #define header guard pattern.
e28e17e6	2018-02-01T10:36:33	attr: avoid stat'ting files for bare repositories Depending on whether the path we want to look up an attribute for is a file or a directory, the fnmatch function will be called with different flags. Because of this, we have to first stat(3) the path to determine whether it is a file or directory in `git_attr_path__init`. This is wasteful though in bare repositories, where we can already be assured that the path will never exist at all due to there being no worktree. In this case, we will execute an unnecessary syscall, which might be noticeable on networked file systems. What happens right now is that we always pass the `GIT_DIR_FLAG_UNKOWN` flag to `git_attr_path__init`, which causes it to `stat` the file itself to determine its type. As it is calling `git_path_isdir` on the path, which will always return `false` in case the path does not exist, we end up with the path always being treated as a file in case of a bare repository. As such, we can just check the bare-repository case in all callers and then pass in `GIT_DIR_FLAG_FALSE` ourselves, avoiding the need to `stat`. While this may not always be correct, it at least is no different from our current behavior.
341608dc	2018-01-31T14:48:42	Merge pull request #4507 from tomas/patch-1 Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current`
9d8510b3	2018-01-31T09:28:43	Merge pull request #4488 from libgit2/ethomson/conflict_marker_size Use longer conflict markers in recursive merge base
054e4c08	2018-01-31T14:28:25	Set ctime/mtime nanosecs to 0 if USE_NSEC is not defined
752006dd	2018-01-30T23:21:19	Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current` This should have been part of PR #3638. Without this we still get nsec-related errors, even when using -DGIT_USE_NSEC: error: ‘struct stat’ has no member named ‘st_mtime_nsec’
275f103d	2018-01-12T08:59:40	odb: reject reading and writing null OIDs The null OID (hash with all zeroes) indicates a missing object in upstream git and is thus not a valid object ID. Add defensive measurements to avoid writing such a hash to the object database in the very unlikely case where some data results in the null OID. Furthermore, add shortcuts when reading the null OID from the ODB to avoid ever returning an object when a faulty repository may contain the null OID.
c0487bde	2018-01-12T08:23:43	tree: reject writing null-OID entries to a tree In commit a96d3cc3f (cache-tree: reject entries with null sha1, 2017-04-21), the git.git project has changed its stance on null OIDs in tree objects. Previously, null OIDs were accepted in tree entries to help tools repair broken history. This resulted in some problems though in that many code paths mistakenly passed null OIDs to be added to a tree, which was not properly detected. Align our own code base according to the upstream change and reject writing tree entries early when the OID is all-zero.
d23ce187	2018-01-22T11:55:28	odb: export mempack backend Fixes #4492, #4496.
7f52bc5a	2018-01-20T18:19:26	xdiff: upgrade to git's included xdiff Upgrade xdiff to git's most recent version, which includes changes to CR/LF handling. Now CR/LF included in the input files will be detected and conflict markers will be emitted with CR/LF when appropriate.
185b0d08	2018-01-20T19:41:28	merge: recursive uses larger conflict markers Git uses longer conflict markers in the recursive merge base - two more than the default (thus, 9 character long conflict markers). This allows users to tell the difference between the recursive merge conflicts and conflicts between the ours and theirs branches. This was introduced in git d694a17986a28bbc19e2a6c32404ca24572e400f. Update our tests to expect this as well.
b8e9467a	2018-01-20T19:39:34	merge: allow custom conflict marker size Allow for a custom conflict marker size, allowing callers to override the default size of the "<<<<<<<" and ">>>>>>>" markers in the conflicted output file.
45f58409	2018-01-20T15:15:40	Merge pull request #4484 from pks-t/pks/fail-creating-branch-HEAD branch: refuse creating branches named 'HEAD'
4ea8035d	2018-01-20T14:56:51	Merge pull request #4478 from libgit2/cmn/packed-refs-sorted refs: include " sorted " in our packed-refs header
a9677e01	2018-01-19T09:20:59	branch: refuse creating branches named 'HEAD' Since a625b092c (branch: correctly reject refs/heads/{-dash,HEAD}, 2017-11-14), which is included in v2.16.0, upstream git refuses to create branches which are named HEAD to avoid ambiguity with the symbolic HEAD reference. Adjust our own code to match that behaviour and reject creating branches names HEAD.

d9007dc8

2018-04-03T11:36:27

Merge pull request #4607 from Sp1l/private/fix-libressl-2.7 Fix build with LibreSSL 2.7

c42261a3

2018-04-03T09:38:38

Merge pull request #4603 from pks-t/pks/appveyor-winhttp-workaround appveyor: workaround for intermittent test failures

b5e0cfa7

2018-04-03T09:32:33

Merge pull request #4601 from bgermann/master sha1dc: update to fix errors with endianess

7490d449

2018-04-02T20:00:07

Fix build with LibreSSL 2.7 LibreSSL 2.7 adds OpenSSL 1.1 API Signed-off-by: Bernard Spil <brnrd@FreeBSD.org>

dc27772c

2018-03-30T13:12:26

Merge pull request #4378 from cjhoward92/fix/submodule-add-check-index submodule: check index for path and prefix before adding submodule

fbe52fa3

2018-03-29T10:18:51

util: fix missing headers for MinGW environments There are multiple references to undefined functions in the Microsoft builds. Add headers to make them known.

b6276ae0

2018-03-29T09:15:48

odb: mempack: fix leaking objects when freeing mempacks When a ODB mempack gets free'd, we take no measures at all to free its contents, most notably the objects added to the database, resulting in a memory leak. Call `git_mempack_reset` previous to freeing the ODB structures themselves, which takes care of releasing all associated data structures.

c9e5ba09

2018-03-28T17:37:39

sha1dc: update to fix errors with endianess This updates the version of SHA1DC to c3e1304ea3.

69a282da

2018-03-28T06:48:55

submodule: add more robust error handling when a submodule path is found on add

c07abd65

2018-03-27T07:37:34

submodule: add better error handling to is_path_occupied

b282ca79

2018-01-06T10:57:32

submodule: change can_add_submodule to is_path_occupied

ef9a7749

2017-11-19T20:59:59

submodule: update index check to check path before directory and fix tests

9371149f

2017-10-20T14:24:01

submodule: fix styling errors

ad1c4350

2017-10-16T15:30:47

submodule: check index for prefix before adding submodule submodule: check path and prefix before adding submodule submodule: fix test errors

cdd0bc2f

2018-03-26T18:44:13

checkout: change default strategy to SAFE As per #4200, our default is quite surprising to users that expect checkout to just "do the thing".

a52b4c51

2018-03-23T09:59:46

odb: fix writing to fake write streams In commit 7ec7aa4a7 (odb: assert on logic errors when writing objects, 2018-02-01), the check for whether we are trying to overflowing the fake stream buffer was changed from returning an error to raising an assert. The conversion forgot though that the logic around `assert`s are basically inverted. Previously, if the statement stream->written + len > steram->size evaluated to true, we would return a `-1`. Now we are asserting that this statement is true, and in case it is not we will raise an error. So the conversion to the `assert` in fact changed the behaviour to the complete opposite intention. Fix the assert by inverting its condition again and add a regression test.

0e4f3d9d

2018-03-03T21:47:22

gitno_extract_url_parts: decode hostnames RFC 3986 says that hostnames can be percent encoded. Percent decode hostnames in our URLs.

05551ca0

2018-03-03T20:14:54

Remove now unnecessary `gitno_unescape`

60e7848e

2018-03-03T20:13:30

gitno_extract_url_parts: use `git_buf`s Now that we can decode percent-encoded strings as part of `git_buf`s, use that decoder in `gitno_extract_url_parts`.

6f577906

2018-03-03T20:09:09

ssh urls: use `git_buf_decode_percent` Use `git_buf_decode_percent` so that we can avoid allocating a temporary buffer.

8070a357

2018-03-03T18:47:35

Introduce `git_buf_decode_percent` Introduce a function to take a percent-encoded string (URI encoded, described by RFC 1738) and decode it into a `git_buf`.

16210877

2018-02-28T12:59:47

Unescape repo before constructing ssh request

8a2cdbd3

2018-02-28T12:58:58

Rename unescape and make non-static

3db1af1f

2018-03-08T12:36:46

index: error out on unreasonable prefix-compressed path lengths When computing the complete path length from the encoded prefix-compressed path, we end up just allocating the complete path without ever checking what the encoded path length actually is. This can easily lead to a denial of service by just encoding an unreasonable long path name inside of the index. Git already enforces a maximum path length of 4096 bytes. As we also have that enforcement ready in some places, just make sure that the resulting path is smaller than GIT_PATH_MAX. Reported-by: Krishna Ram Prakash R <krp@gtux.in> Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>

3207ddb0

2018-03-08T12:00:27

index: fix out-of-bounds read with invalid index entry prefix length The index format in version 4 has prefix-compressed entries, where every index entry can compress its path by using a path prefix of the previous entry. Since implmenting support for this index format version in commit 5625d86b9 (index: support index v4, 2016-05-17), though, we do not correctly verify that the prefix length that we want to reuse is actually smaller or equal to the amount of characters than the length of the previous index entry's path. This can lead to a an integer underflow and subsequently to an out-of-bounds read. Fix this by verifying that the prefix is actually smaller than the previous entry's path length. Reported-by: Krishna Ram Prakash R <krp@gtux.in> Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>

58a6fe94

2018-03-08T11:49:19

index: convert `read_entry` to return entry size via an out-param The function `read_entry` does not conform to our usual coding style of returning stuff via the out parameter and to use the return value for reporting errors. Due to most of our code conforming to that pattern, it has become quite natural for us to actually return `-1` in case there is any error, which has also slipped in with commit 5625d86b9 (index: support index v4, 2016-05-17). As the function returns an `size_t` only, though, the return value is wrapped around, causing the caller of `read_tree` to continue with an invalid index entry. Ultimately, this can lead to a double-free. Improve code and fix the bug by converting the function to return the index entry size via an out parameter and only using the return value to indicate errors. Reported-by: Krishna Ram Prakash R <krp@gtux.in> Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>

53e692af

2018-03-02T12:49:54

worktree: rename parameter creason to reason

12356076

2018-03-02T12:41:04

worktree: lock reason should be const

8a8ea1db

2018-02-28T18:14:52

Merge pull request #4552 from libgit2/cmn/config-header-common Cast less blindly between configuration objects

e8e490b2

2018-02-28T17:01:47

Merge pull request #4554 from pks-t/pks/curl-init curl: initialize and cleanup global curl state

9cd0c6f1

2018-02-28T16:01:16

config: return an error if config_refresh is called on a snapshot Instead of treating it as a no-op, treat it as a programming error and return the same kind of error as if you called to set or delete variables on a snapshot.

2022b004

2018-02-28T12:06:59

curl: explicitly initialize and cleanup global curl state Our curl-based streams make use of the easy curl interface. This interface automatically initializes and de-initializes the global curl state by calling out to `curl_global_init` and `curl_global_cleanup`. Thus, all global state will be repeatedly re-initialized when creating multiple curl streams in succession. Despite being inefficient, this is not thread-safe due to `curl_global_init` being not thread-safe itself. Thus a multi-threaded programing handling multiple curl streams at the same time is inherently racy. Fix the issue by globally initializing and cleaning up curl's state.

a33deeb4

2018-02-28T12:20:23

win32: strncmp -> git__strncmp The win32 C library is compiled cdecl, however when configured with `STDCALL=ON`, our functions (and function pointers) will use the stdcall calling convention. You cannot set a `__stdcall` function pointer to a `__cdecl` function, so it's easier to just use our `git__strncmp` instead of sorting that mess out.

2424e64c

2018-02-28T12:06:02

config: harden our use of the backend objects a bit When we create an iterator we don't actually know that we have a live config object and we must instead only rely on the header. We fixed it to use this in a previous commit, but this makes it harder to misuse by converting to use the header object in the typecast. We also guard inside the `config_refresh` function against being given a snapshot (although callers right now do check).

1785de4e

2018-02-28T11:46:17

config: move the level field into the header We use it in a few places where we might have a full object or a snapshot so move it to where we can actually access it.

c1524b2e

2018-02-28T11:33:11

config: move the repository to the diskfile header We pass this around and when creating a new iterator we need to read the repository pointer. Put it in a common place so we can reach it regardless of whether we got a full object or a snapshot.

c9d59c61

2018-02-27T12:45:21

Merge pull request #4545 from libgit2/ethomson/checkout_filemode Respect core.filemode in checkout

5ecb6220

2018-02-25T15:46:51

winhttp: enable TLS 1.2 on Windows 7 and earlier Versions of Windows prior to Windows 8 do not enable TLS 1.2 by default, though support may exist. Try to enable TLS 1.2 support explicitly on connections. This request may fail if the operating system does not have TLS 1.2 support - the initial release of Vista lacks TLS 1.2 support (though it is available as a software update) and XP completely lacks TLS 1.2 support. If this request does fail, the HTTP context is still valid, and still maintains the original protocol support. So we ignore the failure from this operation.

934e6a3b

2018-02-27T11:24:30

winhttp: include constants for TLS 1.1/1.2 support For platforms that do not define `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1` and/or `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2`.

8c8db980

2018-02-27T10:32:29

mingw: update TLS option flags Include the constants for `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1` and `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2` so that they can be used by mingw. This updates both the `deps/winhttp` framework (for classic mingw) and adds the defines for mingw64, which does not use that framework.

c214ba19

2018-02-20T00:35:27

checkout: respect core.filemode when comparing filemodes Fixes #4504

894ccf4b

2018-02-20T16:14:54

Merge pull request #4535 from libgit2/ethomson/checkout_typechange_with_index_and_wd checkout: when examining index (instead of workdir), also examine mode

ce7080a0

2018-02-20T10:38:27

diff_tform: fix rename detection with rewrite/delete pair A rewritten file can either be classified as a modification of its contents or of a delete of the complete file followed by an addition of the new content. This distinction becomes important when we want to detect renames for rewrites. Given a scenario where a file "a" has been deleted and another file "b" has been renamed to "a", this should be detected as a deletion of "a" followed by a rename of "a" -> "b". Thus, splitting of the original rewrite into a delete/add pair is important here. This splitting is represented by a flag we can set at the current delta. While the flag is already being set in case we want to break rewrites, we do not do so in case where the `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` flag is set. This can trigger an assert when we try to match the source and target deltas. Fix the issue by setting the `GIT_DIFF_FLAG__TO_SPLIT` flag at the delta when it is a rename target and `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` is set.

d7fea1e1

2018-02-18T16:10:33

checkout: take mode into account when comparing index to baseline When checking out a file, we determine whether the baseline (what we expect to be in the working directory) actually matches the contents of the working directory. This is safe behavior to prevent us from overwriting changes in the working directory. We look at the index to optimize this test: if we know that the index matches the working directory, then we can simply look at the index data compared to the baseline. We have historically compared the baseline to the index entry by oid. However, we must also compare the mode of the two items to ensure that they are identical. Otherwise, we will refuse to update the working directory for a mode change.

f1ad004c

2018-02-18T22:29:48

Merge pull request #4529 from libgit2/ethomson/index_add_requires_files git_index_add_frombuffer: only accept files/links

5f774dbf

2018-02-11T10:14:13

git_index_add_frombuffer: only accept files/links Ensure that the buffer given to `git_index_add_frombuffer` represents a regular blob, an executable blob, or a link. Explicitly reject commit entries (submodules) - it makes little sense to allow users to add a submodule from a string; there's no possible path to success.

92324d84

2018-02-16T11:28:53

util: clean up header includes While "util.h" declares the macro `git__tolower`, which simply resorts to tolower(3P) on Unix-like systems, the <ctype.h> header is only being included in "util.c". Thus, anybody who has included "util.h" without having <ctype.h> included will fail to compile as soon as the macro is in use. Furthermore, we can clean up additional includes in "util.c" and simply replace them with an include for "common.h".

06b8a40f

2018-02-16T11:29:46

Explicitly mark fallthrough cases with comments A lot of compilers nowadays generate warnings when there are cases in a switch statement which implicitly fall through to the next case. To avoid this warning, the last line in the case that is falling through can have a comment matching a regular expression, where one possible comment body would be `/* fall through */`. An alternative to the comment would be an explicit attribute like e.g. `[[clang::fallthrough]` or `__attribute__ ((fallthrough))`. But GCC only introduced support for such an attribute recently with GCC 7. Thus, and also because the fallthrough comment is supported by most compilers, we settle for using comments instead. One shortcoming of that method is that compilers are very strict about that. Most interestingly, that comment _really_ has to be the last line. In case a closing brace follows the comment, the heuristic will fail.

7c6e9175

2018-02-16T11:11:11

index: shut up warning on uninitialized variable Even though the `entry` variable will always be initialized when `read_entry` returns success and even though we never dereference `entry` in case `read_entry` fails, GCC prints a warning about uninitialized use. Just initialize the pointer to `NULL` in order to shut GCC up.

84f03b3a

2018-02-16T10:48:55

streams: openssl: fix use of uninitialized variable When verifying the server certificate, we do try to make sure that the hostname actually matches the certificate alternative names. In cases where the host is either an IPv4 or IPv6 address, we have to compare the binary representations of the hostname with the declared IP address of the certificate. We only do that comparison in case we were successfully able to parse the hostname as an IP, which would always result in the memory region being initialized. Still, GCC 6.4.0 was complaining about usage of non-initialized memory. Fix the issue by simply asserting that `addr` needs to be initialized. This shuts up the GCC warning.

ee6be190

2018-01-31T08:36:19

http: standardize user-agent addition The winhttp and posix http each need to add the user-agent to their requests. Standardize on a single function to include this so that we do not get the version numbers we're sending out of sync. Assemble the complete user agent in `git_http__user_agent`, returning assembled strings. Co-authored-by: Patrick Steinhardt <ps@pks.im>

178fda8a

2018-02-09T17:55:18

hash: win32: fix missing comma in `giterr_set`

638c6b8c

2018-02-09T17:32:15

odb_loose: only close file descriptor if it was opened successfully

a43bcd2c

2018-02-09T17:31:50

odb: fix memory leaks due to not freeing hash context

9985edb5

2018-02-01T06:32:55

hash: set error messages on failure

619f61a8

2018-02-01T06:22:36

odb: error when we can't create object header Return an error to the caller when we can't create an object header for some reason (printf failure) instead of simply asserting.

7ec7aa4a

2018-02-01T05:54:57

odb: assert on logic errors when writing objects There's no recovery possible if we're so confused or corrupted that we're trying to overwrite our memory. Simply assert.

138e4c2b

2018-02-01T06:35:31

git_odb__hashfd: propagate error on failures

35ed256b

2018-02-01T05:11:05

git_odb__hashobj: provide errors messages on failures Provide error messages on hash failures: assert when given invalid input instead of failing with a user error; provide error messages on program errors.

59d99adc

2018-01-31T09:34:52

odb: check for alloc errors on hardcoded objects It's unlikely that we'll fail to allocate a single byte, but let's check for allocation failures for good measure. Untangle `-1` being a marker of not having found the hardcoded odb object; use that to reflect actual errors.

ef902864

2018-01-31T09:30:51

odb: error when we can't alloc an object At the moment, we're swallowing the allocation failure. We need to return the error to the caller.

0fd0bfe4

2018-02-08T22:51:46

Merge pull request #4450 from libgit2/ethomson/odb_loose_readstream Streaming read support for the loose ODB backend

d749822c

2018-02-08T22:50:58

Merge pull request #4491 from libgit2/ethomson/recursive Recursive merge: reverse the order of merge bases

ba4faf6e

2018-02-08T17:15:33

buf_text: remove `offset` parameter of BOM detection function The function to detect a BOM takes an offset where it shall look for a BOM. No caller uses that, and searching for the BOM in the middle of a buffer seems to be very unlikely, as a BOM should only ever exist at file start. Remove the parameter, as it has already caused confusion due to its weirdness.

2eea5f1c

2018-02-08T10:27:31

config_parse: fix reading files with BOM The function `skip_bom` is being used to detect and skip BOM marks previously to parsing a configuration file. To do so, it simply uses `git_buf_text_detect_bom`. But since the refactoring to use the parser interface in commit 9e66590bd (config_parse: use common parser interface, 2017-07-21), the BOM detection was actually broken. The issue stems from a misunderstanding of `git_buf_text_detect_bom`. It was assumed that its third parameter limits the length of the character sequence that is to be analyzed, while in fact it was an offset at which we want to detect the BOM. Fix the parameter to be `0` instead of the buffer length, as we always want to check the beginning of the configuration file.

848153f3

2018-02-08T10:02:29

config_parse: handle empty lines with CRLF Currently, the configuration parser will fail reading empty lines with just an CRLF-style line ending. Special-case the '\r' character in order to handle it the same as Unix-style line endings. Add tests to spot this regression in the future.

5340ca77

2018-02-08T09:31:51

config_parse: add comment to clarify logic getting next character Upon each line, the configuration parser tries to get either the first non-whitespace character or the first whitespace character, in case there is no non-whitespace character. The logic handling this looks rather odd and doesn't immediately convey this meaning, so add a comment to clarify what happens.

1403c612

2018-01-22T14:44:31

merge: virtual commit should be last argument to merge-base Our virtual commit must be the last argument to merge-base: since our algorithm pushes _both_ parents of the virtual commit, it needs to be the last argument, since merge-base: > Given three commits A, B and C, git merge-base A B C will compute the > merge base between A and a hypothetical commit M We want to calculate the merge base between the actual commit ("two") and the virtual commit ("one") - since one actually pushes its parents to the merge-base calculation, we need to calculate the merge base of "two" and the parents of one.

b924df1e

2018-01-21T18:05:45

merge: reverse merge bases for recursive merge When the commits being merged have multiple merge bases, reverse the order when creating the virtual merge base. This is for compatibility with git's merge-recursive algorithm, and ensures that we build identical trees. Git does this to try to use older merge bases first. Per 8918b0c: > It seems to be the only sane way to do it: when a two-head merge is > done, and the merge-base and one of the two branches agree, the > merge assumes that the other branch has something new. > > If we start creating virtual commits from newer merge-bases, and go > back to older merge-bases, and then merge with newer commits again, > chances are that a patch is lost, _because_ the merge-base and the > head agree on it. Unlikely, yes, but it happened to me.

ed51feb7

2018-01-21T18:01:20

oidarray: introduce git_oidarray__reverse Provide a simple function to reverse an oidarray.

26f5d36d

2018-02-04T10:27:39

Merge pull request #4489 from libgit2/ethomson/conflicts_crlf Conflict markers should match EOL style in conflicting files

8abd514c

2018-02-02T17:37:12

Merge pull request #4499 from pks-t/pks/setuid-config sysdir: do not use environment in setuid case

2553cbe3

2018-02-02T11:33:46

Merge pull request #4512 from libgit2/ethomson/header_guards Consistent header guards

53454b68

2018-02-02T11:31:15

Merge pull request #4510 from pks-t/pks/attr-file-bare-stat attr: avoid stat'ting files for bare repositories

0967459e

2018-01-25T13:11:34

sysdir: do not use environment in setuid case In order to derive the location of some Git directories, we currently use the environment variables $HOME and $XDG_CONFIG_HOME. This might prove to be problematic whenever the binary is run with setuid, that is when the effective user does not equal the real user. In case the environment variables do not get sanitized by the caller, we thus might end up using the real user's configuration when doing stuff as the effective user. The fix is to use the passwd entry's directory instead of $HOME in this situation. As this might break scenarios where the user explicitly sets $HOME to another path, this fix is only applied in case the effective user does not equal the real user.

09df354e

2018-02-01T16:52:43

odb_loose: HEADER_LEN -> MAX_HEADER_LEN `MAX_HEADER_LEN` is a more descriptive constant name.

624614b2

2017-12-19T00:43:49

odb_loose: validate length when checking for zlib content When checking to see if a file has zlib deflate content, make sure that we actually have read at least two bytes before examining the array.

1118ba3e

2017-12-18T23:08:40

odb_loose: `read_header` for packlike loose objects Support `read_header` for "packlike loose objects", which were a temporarily and uncommonly used format loose object format that encodes the header before the zlib deflate data. This will never actually be seen in the wild, but add support for it for completeness and (more importantly) because our corpus of test data has objects in this format, so it's easier to support it than to try to special case it.

4c7a16b7

2017-12-18T15:56:21

odb_loose: read_header should use zstream Make `read_header` use the common zstream implementation. Remove the now unnecessary zlib wrapper in odb_loose.

6155e06b

2017-12-17T18:44:02

zstream: introduce a single chunk reader Introduce `get_output_chunk` that will inflate/deflate all the available input buffer into the output buffer. `get_output` will call `get_output_chunk` in a loop, while other consumers can use it to inflate only a piece of the data.

80dc3946

2017-12-17T16:26:48

odb_loose: packlike loose objects use `git_zstream` Refactor packlike loose object reads to use `git_zstream` for simplification.

7cb5bae7

2017-12-17T11:55:18

odb: loose object streaming for packlike loose objects A "packlike" loose object was a briefly lived loose object format where the type and size were encoded in uncompressed space at the beginning of the file, followed by the compressed object contents. Handle these in a streaming manner as well.

b61846f2

2017-12-17T02:14:29

odb: introduce streaming loose object reader Provide a streaming loose object reader.

97f9a5f0

2017-12-17T01:12:49

odb: provide length and type with streaming read The streaming read functionality should provide the length and the type of the object, like the normal read functionality does.

c74e9271

2017-12-16T22:10:11

odb_loose: stream -> writestream There are two streaming functions; one for reading, one for writing. Disambiguate function names between `stream` and `writestream` to make allowances for a read stream.

abb04caa

2018-02-01T15:55:48

consistent header guards use consistent names for the #include / #define header guard pattern.

e28e17e6

2018-02-01T10:36:33

attr: avoid stat'ting files for bare repositories Depending on whether the path we want to look up an attribute for is a file or a directory, the fnmatch function will be called with different flags. Because of this, we have to first stat(3) the path to determine whether it is a file or directory in `git_attr_path__init`. This is wasteful though in bare repositories, where we can already be assured that the path will never exist at all due to there being no worktree. In this case, we will execute an unnecessary syscall, which might be noticeable on networked file systems. What happens right now is that we always pass the `GIT_DIR_FLAG_UNKOWN` flag to `git_attr_path__init`, which causes it to `stat` the file itself to determine its type. As it is calling `git_path_isdir` on the path, which will always return `false` in case the path does not exist, we end up with the path always being treated as a file in case of a bare repository. As such, we can just check the bare-repository case in all callers and then pass in `GIT_DIR_FLAG_FALSE` ourselves, avoiding the need to `stat`. While this may not always be correct, it at least is no different from our current behavior.

341608dc

2018-01-31T14:48:42

Merge pull request #4507 from tomas/patch-1 Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current`

9d8510b3

2018-01-31T09:28:43

Merge pull request #4488 from libgit2/ethomson/conflict_marker_size Use longer conflict markers in recursive merge base

054e4c08

2018-01-31T14:28:25

Set ctime/mtime nanosecs to 0 if USE_NSEC is not defined

752006dd

2018-01-30T23:21:19

Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current` This should have been part of PR #3638. Without this we still get nsec-related errors, even when using -DGIT_USE_NSEC: error: ‘struct stat’ has no member named ‘st_mtime_nsec’

275f103d

2018-01-12T08:59:40

odb: reject reading and writing null OIDs The null OID (hash with all zeroes) indicates a missing object in upstream git and is thus not a valid object ID. Add defensive measurements to avoid writing such a hash to the object database in the very unlikely case where some data results in the null OID. Furthermore, add shortcuts when reading the null OID from the ODB to avoid ever returning an object when a faulty repository may contain the null OID.

c0487bde

2018-01-12T08:23:43

tree: reject writing null-OID entries to a tree In commit a96d3cc3f (cache-tree: reject entries with null sha1, 2017-04-21), the git.git project has changed its stance on null OIDs in tree objects. Previously, null OIDs were accepted in tree entries to help tools repair broken history. This resulted in some problems though in that many code paths mistakenly passed null OIDs to be added to a tree, which was not properly detected. Align our own code base according to the upstream change and reject writing tree entries early when the OID is all-zero.

d23ce187

2018-01-22T11:55:28

odb: export mempack backend Fixes #4492, #4496.

7f52bc5a

2018-01-20T18:19:26

xdiff: upgrade to git's included xdiff Upgrade xdiff to git's most recent version, which includes changes to CR/LF handling. Now CR/LF included in the input files will be detected and conflict markers will be emitted with CR/LF when appropriate.

185b0d08

2018-01-20T19:41:28

merge: recursive uses larger conflict markers Git uses longer conflict markers in the recursive merge base - two more than the default (thus, 9 character long conflict markers). This allows users to tell the difference between the recursive merge conflicts and conflicts between the ours and theirs branches. This was introduced in git d694a17986a28bbc19e2a6c32404ca24572e400f. Update our tests to expect this as well.

b8e9467a

2018-01-20T19:39:34

merge: allow custom conflict marker size Allow for a custom conflict marker size, allowing callers to override the default size of the "<<<<<<<" and ">>>>>>>" markers in the conflicted output file.

45f58409

2018-01-20T15:15:40

Merge pull request #4484 from pks-t/pks/fail-creating-branch-HEAD branch: refuse creating branches named 'HEAD'

4ea8035d

2018-01-20T14:56:51

Merge pull request #4478 from libgit2/cmn/packed-refs-sorted refs: include " sorted " in our packed-refs header

a9677e01

2018-01-19T09:20:59

branch: refuse creating branches named 'HEAD' Since a625b092c (branch: correctly reject refs/heads/{-dash,HEAD}, 2017-11-14), which is included in v2.16.0, upstream git refuses to create branches which are named HEAD to avoid ambiguity with the symbolic HEAD reference. Adjust our own code to match that behaviour and reject creating branches names HEAD.

thodg/libgit2/src

src

Log