src


Log

Author Commit Date CI Message
Carlos Martín Nieto cfed1be8 2018-05-24T20:28:36 submodule: plug leaks from the escape detection
Carlos Martín Nieto a3df20cf 2018-05-24T19:00:13 submodule: the repostiory for _name_is_valid should not be const We might modify caches due to us trying to load the configuration to figure out what kinds of filesystem protections we should have.
Carlos Martín Nieto 08d4b459 2018-05-22T15:48:38 index: stat before creating the entry This is so we have it available for the path validity checking. In a later commit we will start rejecting `.gitmodules` files as symlinks.
Carlos Martín Nieto a9e60994 2018-05-23T08:40:17 path: check for a symlinked .gitmodules in fs-agnostic code We still compare case-insensitively to protect more thoroughly as we don't know what specifics we'll see on the system and it's the behaviour from git.
Carlos Martín Nieto f650153a 2018-05-24T19:05:59 submodule: replace index with strchr which exists on Windows
Carlos Martín Nieto aa003557 2018-05-22T16:13:47 path: reject .gitmodules as a symlink Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
Carlos Martín Nieto 37dc60b6 2018-05-16T11:56:04 path: provide a generic dogit checking function for HFS This lets us check for other kinds of reserved files.
Carlos Martín Nieto 916af8ea 2018-05-14T16:03:15 submodule: also validate Windows-separated paths for validity Otherwise we would also admit `..\..\foo\bar` as a valid path and fail to protect Windows users. Ideally we would check for both separators without the need for the copied string, but this'll get us over the RCE.
Carlos Martín Nieto c7cac088 2018-05-22T15:21:08 path: accept the name length as a parameter We may take in names from the middle of a string so we want the caller to let us know how long the path component is that we should be checking.
Carlos Martín Nieto e6c757a7 2018-04-30T13:47:15 submodule: ignore submodules which include path traversal in their name If the we decide that the "name" of the submodule (i.e. its path inside `.git/modules/`) is trying to escape that directory or otherwise trick us, we ignore the configuration for that submodule. This leaves us with a half-configured submodule when looking it up by path, but it's the same result as if the configuration really were missing. The name check is potentially more strict than it needs to be, but it lets us re-use the check we're doing for the checkout. The function that encapsulates this logic is ready to be exported but we don't want to do that in a security release so it remains internal for now.
Carlos Martín Nieto d7ee21ee 2018-05-22T13:58:24 path: expose dotgit detection functions per filesystem These will be used by the checkout code to detect them for the particular filesystem they're on.
Carlos Martín Nieto f907a6f5 2018-05-18T15:16:53 path: hide the dotgit file functions These can't go into the public API yet as we don't want to introduce API or ABI changes in a security release.
Carlos Martín Nieto 0cc14627 2018-05-16T15:56:04 path: add functions to detect .gitconfig and .gitattributes
Carlos Martín Nieto 26b3cec0 2018-05-16T15:42:08 path: add a function to detect an .gitmodules file Given a path component it knows what to pass to the filesystem-specific functions so we're protected even from trees which try to use the 8.3 naming rules to get around us matching on the filename exactly. The logic and test strings come from the equivalent git change.
Carlos Martín Nieto dd364dde 2018-05-16T14:47:04 path: provide a generic function for checking dogit files on NTFS It checks against the 8.3 shortname variants, including the one which includes the checksum as part of its name.
Patrick Steinhardt 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.
Steven King Jr 16210877 2018-02-28T12:59:47 Unescape repo before constructing ssh request
Steven King Jr 8a2cdbd3 2018-02-28T12:58:58 Rename unescape and make non-static
Edward Thomson 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.
Edward Thomson 05551ca0 2018-03-03T20:14:54 Remove now unnecessary `gitno_unescape`
Edward Thomson 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`.
Edward Thomson 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.
Edward Thomson 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`.
Patrick Steinhardt 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>
Patrick Steinhardt 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>
Patrick Steinhardt 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>
Jacques Germishuys 53e692af 2018-03-02T12:49:54 worktree: rename parameter creason to reason
Jacques Germishuys 12356076 2018-03-02T12:41:04 worktree: lock reason should be const
Patrick Steinhardt 8a8ea1db 2018-02-28T18:14:52 Merge pull request #4552 from libgit2/cmn/config-header-common Cast less blindly between configuration objects
Edward Thomson e8e490b2 2018-02-28T17:01:47 Merge pull request #4554 from pks-t/pks/curl-init curl: initialize and cleanup global curl state
Carlos Martín Nieto 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.
Patrick Steinhardt 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.
Edward Thomson 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.
Carlos Martín Nieto 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).
Carlos Martín Nieto 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.
Carlos Martín Nieto 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.
Edward Thomson c9d59c61 2018-02-27T12:45:21 Merge pull request #4545 from libgit2/ethomson/checkout_filemode Respect core.filemode in checkout
Edward Thomson 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.
Edward Thomson 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`.
Edward Thomson 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.
Edward Thomson c214ba19 2018-02-20T00:35:27 checkout: respect core.filemode when comparing filemodes Fixes #4504
Patrick Steinhardt 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
Patrick Steinhardt 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.
Edward Thomson 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.
Edward Thomson 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
Edward Thomson 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.
Patrick Steinhardt 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".
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Edward Thomson 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>
Patrick Steinhardt 178fda8a 2018-02-09T17:55:18 hash: win32: fix missing comma in `giterr_set`
Patrick Steinhardt 638c6b8c 2018-02-09T17:32:15 odb_loose: only close file descriptor if it was opened successfully
Patrick Steinhardt a43bcd2c 2018-02-09T17:31:50 odb: fix memory leaks due to not freeing hash context
Edward Thomson 9985edb5 2018-02-01T06:32:55 hash: set error messages on failure
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 138e4c2b 2018-02-01T06:35:31 git_odb__hashfd: propagate error on failures
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 0fd0bfe4 2018-02-08T22:51:46 Merge pull request #4450 from libgit2/ethomson/odb_loose_readstream Streaming read support for the loose ODB backend
Edward Thomson d749822c 2018-02-08T22:50:58 Merge pull request #4491 from libgit2/ethomson/recursive Recursive merge: reverse the order of merge bases
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Tyrie Vella 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.
Edward Thomson 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.
Edward Thomson ed51feb7 2018-01-21T18:01:20 oidarray: introduce git_oidarray__reverse Provide a simple function to reverse an oidarray.
Edward Thomson 26f5d36d 2018-02-04T10:27:39 Merge pull request #4489 from libgit2/ethomson/conflicts_crlf Conflict markers should match EOL style in conflicting files
Edward Thomson 8abd514c 2018-02-02T17:37:12 Merge pull request #4499 from pks-t/pks/setuid-config sysdir: do not use environment in setuid case
Edward Thomson 2553cbe3 2018-02-02T11:33:46 Merge pull request #4512 from libgit2/ethomson/header_guards Consistent header guards
Edward Thomson 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
Patrick Steinhardt 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.
Edward Thomson 09df354e 2018-02-01T16:52:43 odb_loose: HEADER_LEN -> MAX_HEADER_LEN `MAX_HEADER_LEN` is a more descriptive constant name.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson b61846f2 2017-12-17T02:14:29 odb: introduce streaming loose object reader Provide a streaming loose object reader.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson abb04caa 2018-02-01T15:55:48 consistent header guards use consistent names for the #include / #define header guard pattern.
Patrick Steinhardt 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.
Edward Thomson 341608dc 2018-01-31T14:48:42 Merge pull request #4507 from tomas/patch-1 Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current`
Edward Thomson 9d8510b3 2018-01-31T09:28:43 Merge pull request #4488 from libgit2/ethomson/conflict_marker_size Use longer conflict markers in recursive merge base
Tomás Pollak 054e4c08 2018-01-31T14:28:25 Set ctime/mtime nanosecs to 0 if USE_NSEC is not defined
Tomás Pollak 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’
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Adrián Medraño Calvo d23ce187 2018-01-22T11:55:28 odb: export mempack backend Fixes #4492, #4496.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 45f58409 2018-01-20T15:15:40 Merge pull request #4484 from pks-t/pks/fail-creating-branch-HEAD branch: refuse creating branches named 'HEAD'
Edward Thomson 4ea8035d 2018-01-20T14:56:51 Merge pull request #4478 from libgit2/cmn/packed-refs-sorted refs: include " sorted " in our packed-refs header
Patrick Steinhardt 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.