- 31 Jan, 2022 1 commit
-
-
git has started adding comment markers to its conflict lines in MERGE_MSG. Match that behavior.
Edward Thomson committed
-
- 30 Jan, 2022 1 commit
-
-
Edward Thomson committed
-
- 11 Nov, 2021 2 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
- 09 Nov, 2021 1 commit
-
-
Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
Edward Thomson committed
-
- 17 Oct, 2021 1 commit
-
-
libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Edward Thomson committed
-
- 08 Aug, 2021 1 commit
-
-
Peter Pettersson committed
-
- 12 May, 2020 1 commit
-
-
We currently use `PRIuMAX` to print an integer of type `size_t` in merge::trees::rename::cache_recomputation. While this works just fine on 64 bit arches, it doesn't on 32 bit ones. As a result, our nightly builds on x86 and arm32 fail. Fix the issue by using `PRIuZ` instead.
Patrick Steinhardt committed
-
- 01 Apr, 2020 1 commit
-
-
When computing renames, we cache the hash signatures for each of the potentially conflicting entries so that we do not need to repeatedly read the file and can at least halfway efficiently determine whether two files are similar enough to be deemed a rename. In order to make the hash signatures meaningful, we require at least four lines of data to be present, resulting in at least four different hashes that can be compared. Files that are deemed too small are not cached at all and will thus be repeatedly re-hashed, which is usually not a huge issue. The issue with above heuristic is in case a file does _not_ have at least four lines, where a line is anything separated by a consecutive run of "\n" or "\0" characters. For example "a\nb" is two lines, but "a\0\0b" is also just two lines. Taken to the extreme, a file that has megabytes of consecutive space- or NUL-only may also be deemed as too small and thus not get cached. As a result, we will repeatedly load its blob, calculate its hash signature just to finally throw it away as we notice it's not of any value. When you've got a comparitively big file that you compare against a big set of potentially renamed files, then the cost simply expodes. The issue can be trivially fixed by introducing negative cache entries. Whenever we determine that a given blob does not have a meaningful representation via a hash signature, we store this negative cache marker and will from then on not hash it again, but also ignore it as a potential rename target. This should help the "normal" case already where you have a lot of small files as rename candidates, but in the above scenario it's savings are extraordinarily high. To verify we do not hit the issue anymore with described solution, this commit adds a test that uses the exact same setup described above with one 50 megabyte blob of '\0' characters and 1000 other files that get renamed. Without the negative cache: $ time ./libgit2_clar -smerge::trees::renames::cache_recomputation >/dev/null real 11m48.377s user 11m11.576s sys 0m35.187s And with the negative cache: $ time ./libgit2_clar -smerge::trees::renames::cache_recomputation >/dev/null real 0m1.972s user 0m1.851s sys 0m0.118s So this represents a ~350-fold performance improvement, but it obviously depends on how many files you have and how big the blob is. The test number were chosen in a way that one will immediately notice as soon as the bug resurfaces.
Patrick Steinhardt committed
-
- 18 Jan, 2020 1 commit
-
-
libgit2 does not use `type_t` suffixes as it's redundant; thus, rename `git_merge_diff_type_t` to `git_merge_diff_t` for consistency.
Edward Thomson committed
-
- 20 Jul, 2019 1 commit
-
-
Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
Patrick Steinhardt committed
-
- 15 Jun, 2019 1 commit
-
-
The majority of functions are named `from_something` (with an underscore) instead of `fromsomething`. Update the blob functions for consistency with the rest of the library.
Edward Thomson committed
-
- 13 Jun, 2019 1 commit
-
-
Since commit 394951ad (tests: allow for simple data-driven tests, 2019-06-07), we have the ability to run a given test suite with multiple variants. Use this new feature to deduplicate the test suites for merge::{trees,workdir}::analysis into a single test suite.
Patrick Steinhardt committed
-
- 10 Jun, 2019 5 commits
-
-
Wrap some missed setup api calls in asserts.
Robert Coup committed -
- whitespace -> tabs - comment style - improve repo naming in merge/trees/analysis tests.
Robert Coup committed -
- move duplication between merge/trees/ and merge/workdir/ into merge/analysis{.c,.h} - remove merge-resolve.git resource, open the existing merge-resolve as a bare repo instead.
Robert Coup committed -
Robert Coup committed
-
dupe of workdir/analysis.c against a bare repo.
Robert Coup committed
-
- 14 Dec, 2018 1 commit
-
-
Carlos Martín Nieto committed
-
- 01 Dec, 2018 1 commit
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed
-
- 19 Oct, 2018 1 commit
-
-
This moves the current merge analysis code into a more generic version that can work against any reference. Also change the tests to check returned analysis values exactly.
Etienne Samson committed
-
- 13 Jul, 2018 1 commit
-
-
C++ style comment ("//") are not specified by the ISO C90 standard and thus do not conform to it. While libgit2 aims to conform to C90, we did not enforce it until now, which is why quite a lot of these non-conforming comments have snuck into our codebase. Do a tree-wide conversion of all C++ style comments to the supported C style comments to allow us enforcing strict C90 compliance in a later commit.
Patrick Steinhardt committed
-
- 06 Jul, 2018 1 commit
-
-
Reported by Coverity, CID 1393678-1393697.
Etienne Samson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 04 Feb, 2018 3 commits
-
-
Edward Thomson committed
-
Virtual base building: ensure that the virtual base is created and revwalked in the same way as git.
Edward Thomson committed -
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 committed
-
- 21 Jan, 2018 2 commits
-
-
Ensure that when the files being merged have CR/LF line endings that the conflict markers produced in the conflict file also have CR/LF line endings.
Edward Thomson committed -
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 committed
-
- 04 Dec, 2017 1 commit
-
-
David Turner committed
-
- 11 Nov, 2017 1 commit
-
-
Adds a test case for the issue #4203, when diverging indexes on memory and disk cause git merge to abort with GIT_ECONFLICT
Etiene Dalcol committed
-
- 09 Feb, 2017 1 commit
-
-
Test that shows that submodules are incorrectly considered in renames, and `git_merge_trees` will fail to lookup the submodule as a blob.
Edward Thomson committed
-
- 01 Jan, 2017 1 commit
-
-
When `GIT_MERGE_FIND_RENAMES` is set, provide a default for `rename_threshold` when it is unset.
Edward Thomson committed
-
- 26 May, 2016 1 commit
-
-
Edward Thomson committed
-
- 17 Mar, 2016 6 commits
-
-
Edward Thomson committed
-
Since the `apply` callback can defer, the `check` callback is not necessary. Removing the `check` callback further makes the `payload` unnecessary along with the `cleanup` callback.
Edward Thomson committed -
Ensure that setting the merge attribute forces the built-in default `text` driver and does *not* honor the `merge.default` configuration option. Further ensure that unsetting the merge attribute forces a conflict (the `binary` driver).
Edward Thomson committed -
Edward Thomson committed
-
When a `check` or `apply` callback function returns `GIT_EMERGECONFLICT` stop and product a conflict.
Edward Thomson committed -
When a `check` or `apply` callback function returns `GIT_PASSTHROUGH`, move on to the default merge driver.
Edward Thomson committed
-