summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* 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
| * | consistent header guardsethomson/header_guardsEdward Thomson2018-02-0148-86/+92
| | | | | | | | | | | | use consistent names for the #include / #define header guard pattern.
* | | Merge pull request #4510 from pks-t/pks/attr-file-bare-statEdward Thomson2018-02-022-4/+20
|\ \ \ | |/ / |/| | attr: avoid stat'ting files for bare repositories
| * | attr: avoid stat'ting files for bare repositoriesPatrick Steinhardt2018-02-012-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #4507 from tomas/patch-1Edward Thomson2018-01-311-2/+7
|\ \ \ | | | | | | | | Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current`
| * | | Set ctime/mtime nanosecs to 0 if USE_NSEC is not definedTomás Pollak2018-01-311-0/+3
| | | |
| * | | Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current`Tomás Pollak2018-01-301-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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’
* | | | Merge pull request #4488 from libgit2/ethomson/conflict_marker_sizeEdward Thomson2018-01-312-0/+3
|\ \ \ \ | |/ / / |/| | | Use longer conflict markers in recursive merge base
| * | | merge: recursive uses larger conflict markersEdward Thomson2018-01-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | merge: allow custom conflict marker sizeEdward Thomson2018-01-211-0/+2
| | |/ | |/| | | | | | | | | | | | | Allow for a custom conflict marker size, allowing callers to override the default size of the "<<<<<<<" and ">>>>>>>" markers in the conflicted output file.
* | | odb: reject reading and writing null OIDsPatrick Steinhardt2018-01-261-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | tree: reject writing null-OID entries to a treePatrick Steinhardt2018-01-261-0/+6
| |/ |/| | | | | | | | | | | | | | | | | | | | | 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.
* | odb: export mempack backendAdrián Medraño Calvo2018-01-221-0/+1
|/ | | | Fixes #4492, #4496.
* Merge pull request #4484 from pks-t/pks/fail-creating-branch-HEADEdward Thomson2018-01-201-0/+6
|\ | | | | branch: refuse creating branches named 'HEAD'
| * branch: refuse creating branches named 'HEAD'Patrick Steinhardt2018-01-191-0/+6
| | | | | | | | | | | | | | | | 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.
* | Merge pull request #4478 from libgit2/cmn/packed-refs-sortedEdward Thomson2018-01-201-1/+1
|\ \ | |/ |/| refs: include " sorted " in our packed-refs header
| * refs: include " sorted " in our packed-refs headercmn/packed-refs-sortedCarlos Martín Nieto2018-01-121-1/+1
| | | | | | | | | | | | | | This lets git know that we do in fact have written our packed-refs file sorted (which is apparently not necessarily the case) and it can then use the new-ish mmaped access which lets it avoid significant amounts of effort parsing potentially large files to get to a single piece of data.
* | Merge pull request #4451 from libgit2/charliesome/trailer-infoBrian Lopez2018-01-171-0/+416
|\ \ | | | | | | Implement message trailer parsing API
| * | rename find_trailer to extract_trailer_blockcharliesome/trailer-infoBrian Lopez2018-01-171-2/+2
| | |
| * | Change trailer API to return a simple arrayBrian Lopez2018-01-161-5/+19
| | |
| * | Merge remote-tracking branch 'origin/master' into charliesome/trailer-infoBrian Lopez2018-01-109-54/+99
| |\ \ | | |/
| * | make separators const a macro as wellBrian Lopez2018-01-031-5/+4
| | |
| * | make comment_line_char const a macroBrian Lopez2018-01-031-4/+4
| | |
| * | Merge remote-tracking branch 'origin/master' into charliesome/trailer-infoBrian Lopez2018-01-0228-399/+563
| |\ \
| * | | trailer: use git__prefixcmp instead of starts_withCharlie Somerville2017-12-201-15/+3
| | | |
| * | | trailer: remove inline specifier on is_blank_lineCharlie Somerville2017-12-201-1/+1
| | | |
| * | | message: add routine for parsing trailers from messagesCharlie Somerville2017-12-191-0/+415
| | | | | | | | | | | | | | | | | | | | This is implemented in trailer.c and borrows a large amount of logic from Git core to ensure compatibility.
* | | | transports: local: fix memory leak in reference walkPatrick Steinhardt2018-01-121-0/+2
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | Upon downloading the pack file, the local transport will iterate through every reference using `git_reference_foreach`. The function is a bit tricky though in that it requires the passed callback to free the references, which does not currently happen. Fix the memory leak by freeing all passed references in the callback.
* | | cmake: add openssl to the private deps list when it's the TLS implementationCarlos Martín Nieto2018-01-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We might want OpenSSL to be the implementation for SHA-1 and/or TLS. If we only want it for TLS (e.g. we're building with the collision-detecting SHA-1 implementation) then we did not indicate this to the systems including us a static library. Add OpenSSL to the list also during the TLS decision to make sure we say we should link to it if we use it for TLS.
* | | cmake: treat LIBGIT2_PC_REQUIRES as a listCarlos Martín Nieto2018-01-081-2/+5
| | | | | | | | | | | | | | | | | | It is indeed a list of dependencies for those which include the static archive. This is in preparation for adding two possible places where we might add openssl as a dependency.
* | | Merge pull request #4398 from pks-t/pks/generic-sha1Edward Thomson2018-01-051-20/+26
|\ \ \ | | | | | | | | cmake: allow explicitly choosing SHA1 backend
| * | | cmake: allow explicitly choosing SHA1 backendPatrick Steinhardt2018-01-041-20/+26
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | Right now, if SHA1DC is disabled, the SHA1 backend is mostly chosen based on which system libgit2 is being compiled on and which libraries have been found. To give developers and distributions more choice, enable them to request specific backends by passing in a `-DSHA1_BACKEND=<BACKEND>` option instead. This completely replaces the previous auto-selection.
* | | Merge pull request #4437 from pks-t/pks/openssl-hash-errorsEdward Thomson2018-01-032-8/+31
|\ \ \ | | | | | | | | hash: openssl: check return values of SHA1_* functions
| * | | streams: openssl: fix thread-safety for OpenSSL error messagesPatrick Steinhardt2018-01-031-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function `ERR_error_string` can be invoked without providing a buffer, in which case OpenSSL will simply return a string printed into a static buffer. Obviously and as documented in ERR_error_string(3), this is not thread-safe at all. As libgit2 is a library, though, it is easily possible that other threads may be using OpenSSL at the same time, which might lead to clobbered error strings. Fix the issue by instead using a stack-allocated buffer. According to the documentation, the caller has to provide a buffer of at least 256 bytes of size. While we do so, make sure that the buffer will never get overflown by switching to `ERR_error_string_n` to specify the buffer's size.
| * | | hash: openssl: check return values of SHA1_* functionsPatrick Steinhardt2018-01-031-3/+18
| | |/ | |/| | | | | | | | | | | | | The OpenSSL functions `SHA1_Init`, `SHA1_Update` and `SHA1_Final` all return 1 for success and 0 otherwise, but we never check their return values. Do so.
* | | Merge pull request #4462 from pks-t/pks/diff-generated-excessive-statsEdward Thomson2018-01-035-10/+20
|\ \ \ | | | | | | | | diff_generate: avoid excessive stats of .gitattribute files
| * | | diff_generate: avoid excessive stats of .gitattribute filesPatrick Steinhardt2018-01-035-10/+20
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When generating a diff between two trees, for each file that is to be diffed we have to determine whether it shall be treated as text or as binary files. While git has heuristics to determine which kind of diff to generate, users can also that default behaviour by setting or unsetting the 'diff' attribute for specific files. Because of that, we have to query gitattributes in order to determine how to diff the current files. Instead of hitting the '.gitattributes' file every time we need to query an attribute, which can get expensive especially on networked file systems, we try to cache them instead. This works perfectly fine for every '.gitattributes' file that is found, but we hit cache invalidation problems when we determine that an attribuse file is _not_ existing. We do create an entry in the cache for missing '.gitattributes' files, but as soon as we hit that file again we invalidate it and stat it again to see if it has now appeared. In the case of diffing large trees with each other, this behaviour is very suboptimal. For each pair of files that is to be diffed, we will repeatedly query every directory component leading towards their respective location for an attributes file. This leads to thousands or even hundreds of thousands of wasted syscalls. The attributes cache already has a mechanism to help in that scenario in form of the `git_attr_session`. As long as the same attributes session is still active, we will not try to re-query the gitmodules files at all but simply retain our currently cached results. To fix our problem, we can create a session at the top-most level, which is the initialization of the `git_diff` structure, and use it in order to look up the correct diff driver. As the `git_diff` structure is used to generate patches for multiple files at once, this neatly solves our problem by retaining the session until patches for all files have been generated. The fix has been tested with linux.git by calling `git_diff_tree_to_tree` and `git_diff_to_buf` with v4.10^{tree} and v4.14^{tree}. | time | .gitattributes stats without fix | 33.201s | 844614 with fix | 30.327s | 4441 While execution only improved by roughly 10%, the stat(3) syscalls for .gitattributes files decreased by 99.5%. The benchmarks were quite simple with best-of-three timings on Linux ext4 systems. One can assume that for network based file systems the performance gain will be a lot larger due to a much higher latency.
* | | Merge pull request #4439 from tiennou/fix/4352Patrick Steinhardt2018-01-031-5/+7
|\ \ \ | | | | | | | | cmake: create a dummy file for Xcode
| * | | cmake: create a dummy file for XcodeEtienne Samson2017-12-141-5/+7
| | |/ | |/| | | | Otherwise Xcode will happily not-link our git2 target, resulting in a "missing file" error when building eg. examples
* | | Merge pull request #4457 from libgit2/ethomson/tree_error_messagesPatrick Steinhardt2018-01-031-10/+10
|\ \ \ | |_|/ |/| | tree: standard error messages are lowercase
| * | tree: standard error messages are lowercaseethomson/tree_error_messagesEdward Thomson2017-12-311-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | Our standard error messages begin with a lower case letter so that they can be prefixed or embedded nicely. These error messages were missed during the standardization pass since they use the `tree_error` helper function.
* | | Merge pull request #4453 from libgit2/ethomson/spnegoEdward Thomson2018-01-011-4/+13
|\ \ \ | |/ / |/| | winhttp: properly support ntlm and negotiate
| * | winhttp: properly support ntlm and negotiateethomson/spnegoEdward Thomson2017-12-291-4/+13
| | | | | | | | | | | | | | | | | | | | | When parsing unauthorized responses, properly parse headers looking for both NTLM and Negotiate challenges. Set the HTTP credentials to default credentials (using a `NULL` username and password) with the schemes supported by ourselves and the server.
View Lorry Controller Status