summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* win32: strncmp -> git__strncmpethomson/strncmp_stdcallEdward Thomson2018-02-281-1/+1
| | | | | | | | 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.
* Merge pull request #4545 from libgit2/ethomson/checkout_filemodev0.27.0-rc2Edward Thomson2018-02-271-13/+21
|\ | | | | Respect core.filemode in checkout
| * checkout: respect core.filemode when comparing filemodesethomson/checkout_filemodeEdward Thomson2018-02-231-13/+21
| | | | | | | | Fixes #4504
* | winhttp: enable TLS 1.2 on Windows 7 and earlierethomson/winhttpEdward Thomson2018-02-271-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | winhttp: include constants for TLS 1.1/1.2 supportEdward Thomson2018-02-271-5/+8
| | | | | | | | | | For platforms that do not define `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1` and/or `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2`.
* | mingw: update TLS option flagsEdward Thomson2018-02-271-0/+5
|/ | | | | | | | 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.
* Merge pull request #4535 from ↵Patrick Steinhardt2018-02-201-10/+16
|\ | | | | | | | | libgit2/ethomson/checkout_typechange_with_index_and_wd checkout: when examining index (instead of workdir), also examine mode
| * checkout: take mode into account when comparing index to baselineEdward Thomson2018-02-191-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | diff_tform: fix rename detection with rewrite/delete pairPatrick Steinhardt2018-02-201-1/+3
|/ | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #4529 from libgit2/ethomson/index_add_requires_filesEdward Thomson2018-02-181-5/+9
|\ | | | | git_index_add_frombuffer: only accept files/links
| * git_index_add_frombuffer: only accept files/linksethomson/index_add_requires_filesEdward Thomson2018-02-181-5/+9
| | | | | | | | | | | | | | 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.
* | util: clean up header includesPatrick Steinhardt2018-02-162-6/+7
| | | | | | | | | | | | | | | | | | | | | | 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".
* | Explicitly mark fallthrough cases with commentsPatrick Steinhardt2018-02-164-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | index: shut up warning on uninitialized variablePatrick Steinhardt2018-02-161-1/+1
| | | | | | | | | | | | | | | | 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.
* | streams: openssl: fix use of uninitialized variablePatrick Steinhardt2018-02-161-3/+3
|/ | | | | | | | | | | | | | 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.
* http: standardize user-agent additionethomson/user_agentEdward Thomson2018-02-103-27/+30
| | | | | | | | | | | 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>
* hash: win32: fix missing comma in `giterr_set`Patrick Steinhardt2018-02-091-1/+1
|
* odb_loose: only close file descriptor if it was opened successfullyPatrick Steinhardt2018-02-091-1/+2
|
* odb: fix memory leaks due to not freeing hash contextPatrick Steinhardt2018-02-092-0/+3
|
* hash: set error messages on failureethomson/odb_alloc_errorEdward Thomson2018-02-091-8/+33
|
* odb: error when we can't create object headerEdward Thomson2018-02-094-27/+60
| | | | | Return an error to the caller when we can't create an object header for some reason (printf failure) instead of simply asserting.
* odb: assert on logic errors when writing objectsEdward Thomson2018-02-091-2/+1
| | | | | There's no recovery possible if we're so confused or corrupted that we're trying to overwrite our memory. Simply assert.
* git_odb__hashfd: propagate error on failuresEdward Thomson2018-02-091-1/+1
|
* git_odb__hashobj: provide errors messages on failuresEdward Thomson2018-02-091-4/+8
| | | | | | Provide error messages on hash failures: assert when given invalid input instead of failing with a user error; provide error messages on program errors.
* odb: check for alloc errors on hardcoded objectsEdward Thomson2018-02-091-6/+14
| | | | | | | 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.
* odb: error when we can't alloc an objectEdward Thomson2018-02-091-2/+6
| | | | | At the moment, we're swallowing the allocation failure. We need to return the error to the caller.
* Merge pull request #4450 from libgit2/ethomson/odb_loose_readstreamEdward Thomson2018-02-084-222/+385
|\ | | | | Streaming read support for the loose ODB backend
| * odb_loose: HEADER_LEN -> MAX_HEADER_LENethomson/odb_loose_readstreamEdward Thomson2018-02-011-7/+7
| | | | | | | | `MAX_HEADER_LEN` is a more descriptive constant name.
| * odb_loose: validate length when checking for zlib contentEdward Thomson2018-02-011-4/+7
| | | | | | | | | | 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.
| * odb_loose: `read_header` for packlike loose objectsEdward Thomson2018-02-011-20/+46
| | | | | | | | | | | | | | | | | | | | | | 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.
| * odb_loose: read_header should use zstreamEdward Thomson2018-02-011-85/+24
| | | | | | | | | | Make `read_header` use the common zstream implementation. Remove the now unnecessary zlib wrapper in odb_loose.
| * zstream: introduce a single chunk readerEdward Thomson2018-02-012-36/+55
| | | | | | | | | | | | | | 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.
| * odb_loose: packlike loose objects use `git_zstream`Edward Thomson2018-02-011-88/+71
| | | | | | | | | | Refactor packlike loose object reads to use `git_zstream` for simplification.
| * odb: loose object streaming for packlike loose objectsEdward Thomson2018-02-011-37/+84
| | | | | | | | | | | | | | 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.
| * odb: introduce streaming loose object readerEdward Thomson2018-02-011-7/+148
| | | | | | | | Provide a streaming loose object reader.
| * odb: provide length and type with streaming readEdward Thomson2018-02-011-2/+7
| | | | | | | | | | The streaming read functionality should provide the length and the type of the object, like the normal read functionality does.
| * odb_loose: stream -> writestreamEdward Thomson2018-02-011-8/+8
| | | | | | | | | | | | | | 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.
* | Merge pull request #4491 from libgit2/ethomson/recursiveEdward Thomson2018-02-083-8/+31
|\ \ | | | | | | Recursive merge: reverse the order of merge bases
| * | merge: virtual commit should be last argument to merge-baseethomson/recursiveTyrie Vella2018-02-041-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | merge: reverse merge bases for recursive mergeEdward Thomson2018-02-041-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | oidarray: introduce git_oidarray__reverseEdward Thomson2018-02-042-0/+13
| | | | | | | | | | | | Provide a simple function to reverse an oidarray.
* | | buf_text: remove `offset` parameter of BOM detection functionPatrick Steinhardt2018-02-083-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | config_parse: fix reading files with BOMPatrick Steinhardt2018-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | config_parse: handle empty lines with CRLFPatrick Steinhardt2018-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | 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.
* | | config_parse: add comment to clarify logic getting next characterPatrick Steinhardt2018-02-081-0/+5
|/ / | | | | | | | | | | | | | | 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.
* | Merge pull request #4489 from libgit2/ethomson/conflicts_crlfEdward Thomson2018-02-0416-133/+278
|\ \ | | | | | | Conflict markers should match EOL style in conflicting files
| * | xdiff: upgrade to git's included xdiffEdward Thomson2018-01-2116-133/+278
| | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #4499 from pks-t/pks/setuid-configEdward Thomson2018-02-021-7/+74
|\ \ \ | | | | | | | | sysdir: do not use environment in setuid case
| * | | sysdir: do not use environment in setuid casePatrick Steinhardt2018-02-021-7/+74
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #4512 from libgit2/ethomson/header_guardsEdward Thomson2018-02-0248-86/+92
|\ \ \ | | | | | | | | Consistent header guards
View Lorry Controller Status