| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
For sections we will still use the existing one even if the case disagrees, but
the variable always gets written with the case given by the caller.
|
| |\
| |
| | |
Implement a diff indent heuristic
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
`inline` is not portable enough, and the `xdiff` code doesn't import
the `GIT_INLINE` macro. So introduce a new `XDL_INLINE` macro (with
the same definition as `GIT_INLINE`). Use the new macro to inline two
functions in `xdiffi.c`.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Commit a49895b593 (xdl_change_compact(): introduce the concept
of a change group, 2016-08-22) added a "struct group" type
to xdiff/xdiffi.c. But the POSIX system header "grp.h"
already defines "struct group" (it is part of the getgrnam
interface).
Let's resolve by giving the xdiff variant a scoped name,
which is closer to other xdiff types anyway (e.g.,
xdlfile_t, though note that xdiff is fond if typedefs when
Git usually is not).
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some groups of added/deleted lines in diffs can be slid up or down,
because lines at the edges of the group are not unique. Picking good
shifts for such groups is not a matter of correctness but definitely has
a big effect on aesthetics. For example, consider the following two
diffs. The first is what standard Git emits:
--- a/9c572b21dd090a1e5c5bb397053bf8043ffe7fb4:git-send-email.perl
+++ b/6dcfa306f2b67b733a7eb2d7ded1bc9987809edb:git-send-email.perl
@@ -231,6 +231,9 @@ if (!defined $initial_reply_to && $prompting) {
}
if (!$smtp_server) {
+ $smtp_server = $repo->config('sendemail.smtpserver');
+}
+if (!$smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
$smtp_server = $_;
The following diff is equivalent, but is obviously preferable from an
aesthetic point of view:
--- a/9c572b21dd090a1e5c5bb397053bf8043ffe7fb4:git-send-email.perl
+++ b/6dcfa306f2b67b733a7eb2d7ded1bc9987809edb:git-send-email.perl
@@ -230,6 +230,9 @@ if (!defined $initial_reply_to && $prompting) {
$initial_reply_to =~ s/(^\s+|\s+$)//g;
}
+if (!$smtp_server) {
+ $smtp_server = $repo->config('sendemail.smtpserver');
+}
if (!$smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
This patch teaches Git to pick better positions for such "diff sliders"
using heuristics that take the positions of nearby blank lines and the
indentation of nearby lines into account.
The existing Git code basically always shifts such "sliders" as far down
in the file as possible. The only exception is when the slider can be
aligned with a group of changed lines in the other file, in which case
Git favors depicting the change as one add+delete block rather than one
add and a slightly offset delete block. This naive algorithm often
yields ugly diffs.
Commit d634d61ed6 improved the situation somewhat by preferring to
position add/delete groups to make their last line a blank line, when
that is possible. This heuristic does more good than harm, but (1) it
can only help if there are blank lines in the right places, and (2)
always picks the last blank line, even if there are others that might be
better. The end result is that it makes perhaps 1/3 as many errors as
the default Git algorithm, but that still leaves a lot of ugly diffs.
This commit implements a new and much better heuristic for picking
optimal "slider" positions using the following approach: First observe
that each hypothetical positioning of a diff slider introduces two
splits: one between the context lines preceding the group and the first
added/deleted line, and the other between the last added/deleted line
and the first line of context following it. It tries to find the
positioning that creates the least bad splits.
Splits are evaluated based only on the presence and locations of nearby
blank lines, and the indentation of lines near the split. Basically, it
prefers to introduce splits adjacent to blank lines, between lines that
are indented less, and between lines with the same level of indentation.
In more detail:
1. It measures the following characteristics of a proposed splitting
position in a `struct split_measurement`:
* the number of blank lines above the proposed split
* whether the line directly after the split is blank
* the number of blank lines following that line
* the indentation of the nearest non-blank line above the split
* the indentation of the line directly below the split
* the indentation of the nearest non-blank line after that line
2. It combines the measured attributes using a bunch of
empirically-optimized weighting factors to derive a `struct
split_score` that measures the "badness" of splitting the text at
that position.
3. It combines the `split_score` for the top and the bottom of the
slider at each of its possible positions, and selects the position
that has the best `split_score`.
I determined the initial set of weighting factors by collecting a corpus
of Git histories from 29 open-source software projects in various
programming languages. I generated many diffs from this corpus, and
determined the best positioning "by eye" for about 6600 diff sliders. I
used about half of the repositories in the corpus (corresponding to
about 2/3 of the sliders) as a training set, and optimized the weights
against this corpus using a crude automated search of the parameter
space to get the best agreement with the manually-determined values.
Then I tested the resulting heuristic against the full corpus. The
results are summarized in the following table, in column `indent-1`:
| repository | count | Git 2.9.0 | compaction | compaction-fixed | indent-1 | indent-2 |
| --------------------- | ----- | -------------- | -------------- | ---------------- | -------------- | -------------- |
| afnetworking | 109 | 89 (81.7%) | 37 (33.9%) | 37 (33.9%) | 2 (1.8%) | 2 (1.8%) |
| alamofire | 30 | 18 (60.0%) | 14 (46.7%) | 15 (50.0%) | 0 (0.0%) | 0 (0.0%) |
| angular | 184 | 127 (69.0%) | 39 (21.2%) | 23 (12.5%) | 5 (2.7%) | 5 (2.7%) |
| animate | 313 | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) | 2 (0.6%) |
| ant | 380 | 356 (93.7%) | 152 (40.0%) | 148 (38.9%) | 15 (3.9%) | 15 (3.9%) | *
| bugzilla | 306 | 263 (85.9%) | 109 (35.6%) | 99 (32.4%) | 14 (4.6%) | 15 (4.9%) | *
| corefx | 126 | 91 (72.2%) | 22 (17.5%) | 21 (16.7%) | 6 (4.8%) | 6 (4.8%) |
| couchdb | 78 | 44 (56.4%) | 26 (33.3%) | 28 (35.9%) | 6 (7.7%) | 6 (7.7%) | *
| cpython | 937 | 158 (16.9%) | 50 (5.3%) | 49 (5.2%) | 5 (0.5%) | 5 (0.5%) | *
| discourse | 160 | 95 (59.4%) | 42 (26.2%) | 36 (22.5%) | 18 (11.2%) | 13 (8.1%) |
| docker | 307 | 194 (63.2%) | 198 (64.5%) | 253 (82.4%) | 8 (2.6%) | 8 (2.6%) | *
| electron | 163 | 132 (81.0%) | 38 (23.3%) | 39 (23.9%) | 6 (3.7%) | 6 (3.7%) |
| git | 536 | 470 (87.7%) | 73 (13.6%) | 78 (14.6%) | 16 (3.0%) | 16 (3.0%) | *
| gitflow | 127 | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) |
| ionic | 133 | 89 (66.9%) | 29 (21.8%) | 38 (28.6%) | 1 (0.8%) | 1 (0.8%) |
| ipython | 482 | 362 (75.1%) | 167 (34.6%) | 169 (35.1%) | 11 (2.3%) | 11 (2.3%) | *
| junit | 161 | 147 (91.3%) | 67 (41.6%) | 66 (41.0%) | 1 (0.6%) | 1 (0.6%) | *
| lighttable | 15 | 5 (33.3%) | 0 (0.0%) | 2 (13.3%) | 0 (0.0%) | 0 (0.0%) |
| magit | 88 | 75 (85.2%) | 11 (12.5%) | 9 (10.2%) | 1 (1.1%) | 0 (0.0%) |
| neural-style | 28 | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) | 0 (0.0%) |
| nodejs | 781 | 649 (83.1%) | 118 (15.1%) | 111 (14.2%) | 4 (0.5%) | 5 (0.6%) | *
| phpmyadmin | 491 | 481 (98.0%) | 75 (15.3%) | 48 (9.8%) | 2 (0.4%) | 2 (0.4%) | *
| react-native | 168 | 130 (77.4%) | 79 (47.0%) | 81 (48.2%) | 0 (0.0%) | 0 (0.0%) |
| rust | 171 | 128 (74.9%) | 30 (17.5%) | 27 (15.8%) | 16 (9.4%) | 14 (8.2%) |
| spark | 186 | 149 (80.1%) | 52 (28.0%) | 52 (28.0%) | 2 (1.1%) | 2 (1.1%) |
| tensorflow | 115 | 66 (57.4%) | 48 (41.7%) | 48 (41.7%) | 5 (4.3%) | 5 (4.3%) |
| test-more | 19 | 15 (78.9%) | 2 (10.5%) | 2 (10.5%) | 1 (5.3%) | 1 (5.3%) | *
| test-unit | 51 | 34 (66.7%) | 14 (27.5%) | 8 (15.7%) | 2 (3.9%) | 2 (3.9%) | *
| xmonad | 23 | 22 (95.7%) | 2 (8.7%) | 2 (8.7%) | 1 (4.3%) | 1 (4.3%) | *
| --------------------- | ----- | -------------- | -------------- | ---------------- | -------------- | -------------- |
| totals | 6668 | 4391 (65.9%) | 1496 (22.4%) | 1491 (22.4%) | 150 (2.2%) | 144 (2.2%) |
| totals (training set) | 4552 | 3195 (70.2%) | 1053 (23.1%) | 1061 (23.3%) | 86 (1.9%) | 88 (1.9%) |
| totals (test set) | 2116 | 1196 (56.5%) | 443 (20.9%) | 430 (20.3%) | 64 (3.0%) | 56 (2.6%) |
In this table, the numbers are the count and percentage of human-rated
sliders that the corresponding algorithm got *wrong*. The columns are
* "repository" - the name of the repository used. I used the diffs
between successive non-merge commits on the HEAD branch of the
corresponding repository.
* "count" - the number of sliders that were human-rated. I chose most,
but not all, sliders to rate from those among which the various
algorithms gave different answers.
* "Git 2.9.0" - the default algorithm used by `git diff` in Git 2.9.0.
* "compaction" - the heuristic used by `git diff --compaction-heuristic`
in Git 2.9.0.
* "compaction-fixed" - the heuristic used by `git diff
--compaction-heuristic` after the fixes from earlier in this patch
series. Note that the results are not dramatically different than
those for "compaction". Both produce non-ideal diffs only about 1/3 as
often as the default `git diff`.
* "indent-1" - the new `--indent-heuristic` algorithm, using the first
set of weighting factors, determined as described above.
* "indent-2" - the new `--indent-heuristic` algorithm, using the final
set of weighting factors, determined as described below.
* `*` - indicates that repo was part of training set used to determine
the first set of weighting factors.
The fact that the heuristic performed nearly as well on the test set as
on the training set in column "indent-1" is a good indication that the
heuristic was not over-trained. Given that fact, I ran a second round of
optimization, using the entire corpus as the training set. The resulting
set of weights gave the results in column "indent-2". These are the
weights included in this patch.
The final result gives consistently and significantly better results
across the whole corpus than either `git diff` or `git diff
--compaction-heuristic`. It makes only about 1/30 as many errors as the
former and about 1/10 as many errors as the latter. (And a good fraction
of the remaining errors are for diffs that involve weirdly-formatted
code, sometimes apparently machine-generated.)
The tools that were used to do this optimization and analysis, along
with the human-generated data values, are recorded in a separate project
[1].
[1] https://github.com/mhagger/diff-slider-tools
Original Git commit: 433860f3d0beb0c6f205290bd16cda413148f098
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The idea of xdl_change_compact() is fairly simple:
* Proceed through groups of changed lines in the file to be compacted,
keeping track of the corresponding location in the "other" file.
* If possible, slide the group up and down to try to give the most
aesthetically pleasing diff. Whenever it is slid, the current location
in the other file needs to be adjusted.
But these simple concepts are obfuscated by a lot of index handling that
is written in terse, subtle, and varied patterns. I found it very hard
to convince myself that the function was correct.
So introduce a "struct group" that represents a group of changed lines
in a file. Add some functions that perform elementary operations on
groups:
* Initialize a group to the first group in a file
* Move to the next or previous group in a file
* Slide a group up or down
Even though the resulting code is longer, I think it is easier to
understand and review. Its performance is not changed
appreciably (though it would be if `group_next()` and `group_previous()`
were not inlined).
...and in fact, the rewriting helped me discover another bug in the
--compaction-heuristic code: The update of blank_lines was never done
for the highest possible position of the group. This means that it could
fail to slide the group to its highest possible position, even if that
position had a blank line as its last line. So for example, it yielded
the following diff:
$ git diff --no-index --compaction-heuristic a.txt b.txt
diff --git a/a.txt b/b.txt
index e53969f..0d60c5fe 100644
--- a/a.txt
+++ b/b.txt
@@ -1,3 +1,7 @@
1
A
+
+B
+
+A
2
when in fact the following diff is better (according to the rules of
--compaction-heuristic):
$ git diff --no-index --compaction-heuristic a.txt b.txt
diff --git a/a.txt b/b.txt
index e53969f..0d60c5fe 100644
--- a/a.txt
+++ b/b.txt
@@ -1,3 +1,7 @@
1
+A
+
+B
+
A
2
The new code gives the bottom answer.
Original Git commit: e8adf23d1ee97b57c8aea32ee8365203b77c0e42
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
There is no reason for it to take an array and two indexes as argument,
as it only accesses two elements of the array.
Original Git commit: 152598cbb667471c8f5be16e199922a41452b2d5
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is a common pattern in xdl_change_compact to check that hashes and
strings match. The resulting code to perform this change causes very
long lines and makes it hard to follow the intention. Introduce a helper
function recs_match which performs both checks to increase
code readability.
Original Git commit: 92e5b62fec0e9b647429e8d3736c571c434dd375
|
| | | |
| | |
| | |
| | |
| | | |
When trying to decode the private key it looks like LibSSH2 returns a
LIBSSH2_ERROR_PUBLICKEY_UNVERIFIED when the passphrase is incorrect.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Due to our split of CMake files into multiple modules, we had to replace
some uses of the `${CMAKE_CURRENT_SOURCE_DIR}` and
`${CMAKE_CURRENT_BINARY_DIR}` variables and replace them with
`${CMAKE_SOURCE_DIR}` and `${CMAKE_BINARY_DIR}`. This enabled us to
still be able to refer to top-level files when defining build
instructions inside of a subdirectory.
When replacing all variables, it was assumed that the absolute set of
variables is always relative to the current project. But in fact, this
is not the case, as these variables always point to the source and
binary directory as given by the top-levl project. So the change
actually broke the ability to include libgit2 directly as a subproject,
as source files cannot be found anymore.
Fix this by instead using project-specific source and binary directories
with `${libgit2_SOURCE_DIR}` and `${libgit2_BINARY_DIR}`.
|
| |\ \ \
| | | |
| | | | |
cmake: fix linking in Xcode with object libraries only
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
CMake is unable to generate a correct Xcode project when trying to link
libraries with only object libraries as its input. As our new build
infrastructure makes heavy use of object libraries now, this affects our
libgit2 library target, as well, leading to linking errors.
Fix the issue by adding a dummy file to the libgit2 objects. As we
always have the "features.h" header ready which contains defines only,
we can simply link it into the resulting library without any effect
whatsoever. This fixes building with Xcode.
|
| |\ \ \ \
| |/ / /
|/| | | |
transports: smart: fix memory leak when skipping symbolic refs
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When we setup the revision walk for negotiating references with a
remote, we iterate over all references, ignoring tags and symbolic
references. While skipping over symbolic references, we forget to free
the looked up reference, resulting in a memory leak when the next
iteration simply overwrites the variable.
Fix that issue by freeing the reference at the beginning of each
iteration and collapsing return paths for error and success.
|
| |\ \ \ \
| | | | |
| | | | | |
Checkout typechange-only deltas
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
On Windows, we do not support file mode changes, so do not test
for type changes between the disk and tree being checked out.
We could have false positives since the on-disk file can only have
an (effective) mode of 0100644 since NTFS does not support executable
files. If the tree being checked out did have an executable file,
we would erroneously decide that the file on disk had been changed.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When performing a forced checkout, treat files as modified when the
workdir or the index is identical except for the mode. This ensures
that force checkout will update the mode to the target. (Apply this
check for regular files only, if one of the items was a file and the
other was another type of item then this would be a typechange and
handled independently.)
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Plug some leaks in curl's proxy handling
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
When we duplicate a user-provided options struct, we're stuck with freeing the
url in it. In case we add stuff to the proxy struct, let's add a function in
which to put the logic.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
refs: do not use peeled OID if peeling to a tag
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If a reference stored in a packed-refs file does not directly point to a
commit, tree or blob, the packed-refs file will also will include a
fully-peeled OID pointing to the first underlying object of that type.
If we try to peel a reference to an object, we will use that peeled OID
to speed up resolving the object.
As a reference for an annotated tag does not directly point to a commit,
tree or blob but instead to the tag object, the packed-refs file will
have an accomodating fully-peeled OID pointing to the object referenced
by that tag. When we use the fully-peeled OID pointing to the referenced
object when peeling, we obviously cannot peel that to the tag anymore.
Fix this issue by not using the fully-peeled OID whenever we want to
peel to a tag. Note that this does not include the case where we want to
resolve to _any_ object type. Existing code may make use from the fact
that we resolve those to commit objects instead of tag objects, even
though that behaviour is inconsistent between packed and loose
references. Furthermore, some tests of ours make the assumption that we
in fact resolve those references to a commit.
|
| |/ / / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Our bundled deps are being built as simple static libraries which are
then linked into the libgit2 library via `TARGET_LINK_LIBRARIES`. While
this works for a dynamically built libgit2 library, using this function
to link two static libraries does not have the expected outcome of
merging those static libraries into one big library. This leads to
symbols of our bundled deps being undefined in the resulting libgit2
archive.
As we have bumped our minimum CMake version to 2.8.11, we can now easily
make use of object libraries for our bundled dependencies. So build
instructions are still self-contained inside of the dependency
directories and the resulting object libraries can just be added to the
LIBGIT2_OBJECTS list, which will cause them to be linked into the final
resulting static library. This fixes the issue of undefined symbols.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
As we have bumped our minimum CMake version to 2.8.11, we can now
unconditionally make use of object libraries. So remove the version
check for the git2internal object library and always use it.
|
| |/ /
| |
| |
| |
| |
| |
| | |
Distinguish variables keeping track of our internal libgit2 sources and
the final objects which shall be linked into the library. This will ease
the transition to use object libraries for our bundled dependencies
instead of linking them in.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After initializing the hash context in `git_diff_patchid`, we never
proceed to call `git_hash_ctx_cleanup` on it. While this doesn't really
matter on most hash implementations, this causes a memory leak on Win32
due to CNG system requiring a `malloc` call.
Fix the memory leak by always calling `git_hash_ctx_cleanup` before
exiting.
|
| |\ \
| | |
| | | |
Clear the remote_ref_name buffer in git_push_update_tips()
|
| | | |
| | |
| | |
| | |
| | |
| | | |
If fetch_spec was a non-pattern, and it is not the first iteration of push_status vector, then git_refspec_transform would result in the new value appended via git_buf_puts to the previous iteration value.
Forcibly clearing the buffer on each iteration to prevent this behavior.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In commit a390a8464 (cmake: move defines into "features.h" header,
2017-07-01), we have introduced a new "features.h" header. This file is
being generated by the CMake build system based on how the libgit2 build
has been configured, replacing the preexisting method of simply setting
the defines inside of the CMake build system. This was done to help
splitting up the build instructions into multiple separate
subdirectories.
An overlooked shortcoming of this approach is that some projects making
use of libgit2 build the library with custom build systems, without
making use of CMake. For those users, the introduction of the
"features.h" file makes their life harder as they would have to also
generate this file.
Fix this issue by guarding all inclusions of the generated header file
by the `LIBGIT2_NO_FEATURES_H` define. Like this, other build systems
can skip the feature header and simply define all used features by
specifying `-D` flags for the compiler again.
|
| |\ \
| | |
| | | |
Fix negative ignore rules with patterns
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When computing negative ignores, we throw away any rule which does not
undo a previous rule to optimize. But on case insensitive file systems,
we need to keep in mind that a negative ignore can also undo a previous
rule with different case, which we did not yet honor while determining
whether a rule undoes a previous one. So in the following example, we
fail to unignore the "/Case" directory:
/case
!/Case
Make both paths checking whether a plain- or wildcard-based rule undo a
previous rule aware of case-insensitivity. This fixes the described
issue.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ignore rules allow for reverting a previously ignored rule by prefixing
it with an exclamation mark. As such, a negative rule can only override
previously ignored files. While computing all ignore patterns, we try to
use this fact to optimize away some negative rules which do not override
any previous patterns, as they won't change the outcome anyway.
In some cases, though, this optimization causes us to get the actual
ignores wrong for some files. This may happen whenever the pattern
contains a wildcard, as we are unable to reason about whether a pattern
overrides a previous pattern in a sane way. This happens for example in
the case where a gitignore file contains "*.c" and "!src/*.c", where we
wouldn't un-ignore files inside of the "src/" subdirectory.
In this case, the first solution coming to mind may be to just strip the
"src/" prefix and simply compare the basenames. While that would work
here, it would stop working as soon as the basename pattern itself is
different, like for example with "*x.c" and "!src/*.c. As such, we
settle for the easier fix of just not optimizing away rules that contain
a wildcard.
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While it is technically possible to look up submodules inside of a
bare repository by reading the submodule configuration of a specific
commit, we do not offer this functionality right now. As such, calling
both `git_submodule_lookup` and `git_submodule_foreach` should error out
early when these functions encounter a bare repository. While
`git_submodule_lookup` already does return an error due to not being
able to parse the configuration, `git_submodule_foreach` simply returns
success and never invokes the callback function.
Fix the issue by having both functions check whether the repository is
bare and returning an error in that case.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As observed by Edward Thomson, the libgit2 DLL built by Windows will not
end up in the top-level build directory but instead inside of the 'src/'
subdirectory. While confusing at first because we are actually setting
the LIBRARY_OUTPUT_DIRECTORY to the project's binary directory, the
manual page of LIBRARY_OUTPUT_DIRECTORY clears this up:
There are three kinds of target files that may be built: archive,
library, and runtime. Executables are always treated as runtime
targets. Static libraries are always treated as archive targets.
Module libraries are always treated as library targets. For non-DLL
platforms shared libraries are treated as library targets. For DLL
platforms the DLL part of a shared library is treated as a runtime
target and the corresponding import library is treated as an archive
target. All Windows-based systems including Cygwin are DLL
platforms.
So in fact, DLLs and import libraries are not treated as libraries at
all by CMake but instead as runtime and archive targets. To fix the
issue, we can thus simply set the variables RUNTIME_OUTPUT_DIRECTORY and
ARCHIVE_OUTPUT_DIRECTORY to the project's root binary directory.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With c26ce7840 (Merge branch 'AndreyG/cmake/modernization', 2017-06-28),
we have recently introduced a regression in the way we are searching for
headers. We have made sure to always include our own headers first, but
due to the changes in c26ce7840 this is no longer guaranteed. In fact,
this already leads the compiler into picking "config.h" from the
"deps/regex" dependency, if it is used.
Fix the issue by declaring our internal include directories up front,
before any of the other search directories is added.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To fix leaking build instructions into different targets and to make
the build instructions easier to handle, create a new CMakeLists.txt
file containing build instructions for the libgit2 target.
By now, the split is rather easy to achieve. Due to the preparatory
steps, we can now simply move over all related build instructions, only
needing to remove the "src/" prefix from some files.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In our CMakeLists.txt, we have to check multiple functions in order to
determine if we have to use our own or whether we can use the
platform-provided one. For two of these functions, namely `regcomp_l()`
and `futimens`, the defined macro is actually used inside of the header
file "src/unix/posix.h". As such, these macros are not only required by
the library, but also by our test suite, which is makes use of internal
headers.
To prepare for the CMakeLists.txt split, move these two defines inside
of the "features.h" header.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In a future commit, we will split out the build instructions for our
library directory and move them into a subdirectory. One of the benefits
is fixing scoping issues, where e.g. defines do not leak to build
targets where they do not belong to. But unfortunately, this does also
pose the problem of how to propagate some defines which are required by
both the library and the test suite.
One way would be to create another variable keeping track of all added
defines and declare it inside of the parent scope. While this is the
most obvious and simplest way of going ahead, it is kind of unfortunate.
The main reason to not use this is that these defines become implicit
dependencies between the build targets. By simply observing a define
inside of the CMakeLists.txt file, one cannot reason whether this define
is only required by the current target or whether it is required by
different targets, as well.
Another approach would be to use an internal header file keeping track
of all defines shared between targets. While configuring the library, we
will set various variables and let CMake configure the file, adding or
removing defines based on what has been configured. Like this, one can
easily keep track of the current environment by simply inspecting the
header file. Furthermore, these dependencies are becoming clear inside
the CMakeLists.txt, as instead of simply adding a define, we now call
e.g. `SET(GIT_THREADSAFE 1)`.
Having this header file though requires us to make sure it is always
included before any "#ifdef"-preprocessor checks are executed. As we
have already refactored code to always include the "common.h" header
file before any statement inside of a file, this becomes easy: just make
sure "common.h" includes the new "features.h" header file first.
|
| |\ \
| | |
| | | |
Include fixups
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.
This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.
This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.
|
| | | |
| | |
| | |
| | |
| | | |
Some implementation files were missing the license headers. This commit
adds them.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some of our header files are not included at all by any of their
implementing counter-parts. Including them inside of these files leads
to some compile errors mostly due to unknown types because of missing
includes. But there's also one case where a declared function does not
match the implementation's prototype.
Fix all these errors by fixing up the prototype and adding missing
includes. This is preparatory work for fixing up missing includes in the
implementation files.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current order of declarations and includes between "common.h" and
"w32_crtdbg_stacktrace.h" is rather complicated. Both header files make
use of things defined in the other one and are thus circularly dependent
on each other. This makes it currently impossible to compile the
"w32_crtdbg_stacktrace.c" file when including "common.h" inside of
"w32_crtdbg_stacktrace.h".
We can disentangle the mess by moving declaration of the inline crtdbg
functions into the "w32_crtdbg_stacktrace.h" file and adding additional
includes inside of it, such that all required functions are available to
it. This allows us to break the dependency cycle.
|
