summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * | | 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
| | |
View Lorry Controller Status