|
1f9b7222
|
2019-05-22T12:47:04
|
|
cmake: disable fallthrough warnings for PCRE
Our PCRE dependency has uncommented fallthroughs in switch statements.
Turn off warnings for those in the PCRE code.
|
|
|
ca046360
|
2019-05-22T12:18:30
|
|
Merge pull request #5073 from libgit2/ethomson/config_section_validity
Configuration parsing: validate section headers with quotes
|
|
|
355b02a1
|
2019-05-22T11:48:28
|
|
config: rename subsection header parser func
The `parse_section_header_ext` name suggests that it as an extended
function for parsing the section header. It is not. Rename it to
`parse_subsection_header` to better reflect its true mission.
|
|
|
23c5699e
|
2019-05-16T09:37:25
|
|
config: validate quoted section value
When we reach a whitespace after a section name, we assume that what
will follow will be a quoted subsection name. Pass the current position
of the line being parsed to the subsection parser, so that it can
validate that subsequent characters are additional whitespace or a
single quote.
Previously we would begin parsing after the section name, looking for
the first quotation mark. This allows invalid characters to embed
themselves between the end of the section name and the first quotation
mark, eg `[section foo "subsection"]`, which is illegal.
|
|
|
b83bd037
|
2019-05-16T08:57:10
|
|
config: don't write invalid column
When we don't specify a particular column, don't write it in the error
message. (column "0" is unhelpful.)
|
|
|
42dd38dd
|
2019-05-16T08:55:40
|
|
config: lowercase error messages
Update the configuration parsing error messages to be lower-cased for
consistency with the rest of the library.
|
|
|
d97afb93
|
2019-05-22T11:45:45
|
|
Merge pull request #5060 from pks-t/pks/refspec-nested-globs
Loosen restriction on wildcard "*" refspecs
|
|
|
3d9e82fd
|
2019-05-21T14:59:55
|
|
Merge pull request #4935 from libgit2/ethomson/pcre
Use PCRE for our fallback regex engine when regcomp_l is unavailable
|
|
|
954f5357
|
2019-05-21T14:33:37
|
|
Merge pull request #5062 from tiennou/fix/ssh-url-substitution
Remote URL last-chance resolution
|
|
|
afb04a95
|
2019-05-21T14:03:04
|
|
ci: use a mix of regex backends
Explicitly enable the `builtin` regex backend and the PCRE backend for
some Linux builds.
|
|
59647e1a
|
2019-04-08T15:54:25
|
|
remote: add callback to resolve URLs before connecting
Since libssh2 doesn't read host configuration from the config file,
this callback can be used to hand over URL resolving to the client
without touching the SSH implementation itself.
|
|
|
ac2b235e
|
2019-05-21T12:22:40
|
|
regex: use REGEX_BACKEND as the cmake option name
This avoids any misunderstanding with the REGEX keyword in cmake.
|
|
4aa36ff2
|
2019-05-21T12:18:47
|
|
Merge pull request #5075 from libgit2/ethomson/ignore_skip_bom
Skip UTF8 BOM in ignore files
|
|
|
6b9cc029
|
2019-05-21T12:05:50
|
|
Merge pull request #5080 from dbrnz/issue-5079
We've already added `ZLIB_LIBRARIES` to `LIBGIT2_LIBS` so don't also add the `z` library
|
|
ada1cd01
|
2019-05-21T21:35:57
|
|
Use tabs for indentation (#5079).
|
|
|
b575c242
|
2019-05-21T20:20:04
|
|
Fix indentation (#5079).
|
|
|
2c2e924b
|
2019-05-21T20:17:48
|
|
We still need to update pkgconfig variables when zlib is unbundled (#5079).
|
|
|
06dbf734
|
2019-05-21T15:44:32
|
|
We've already added `ZLIB_LIBRARIES` to `LIBGIT2_LIBS` so don't also add the `z` library (libgit2/#5079).
|
|
|
040db8ad
|
2019-05-20T14:11:32
|
|
Merge pull request #5077 from jacquesg/symbolic_link_flag_directory
Define SYMBOLIC_LINK_FLAG_DIRECTORY if required
|
|
0fd259ed
|
2019-05-20T12:44:37
|
|
define SYMBOLIC_LINK_FLAG_DIRECTORY if not defined
|
|
|
133bceba
|
2019-05-19T13:57:13
|
|
ignore: skip UTF8 BOM in ignore file
|
|
|
73a157e0
|
2019-05-19T13:29:45
|
|
ignore: test we can handle an ignore file with BOM
Ensure that we can read and parse an ignore file with a UTF8 BOM.
|
|
|
aea9a712
|
2018-03-02T15:12:14
|
|
tests: regcomp: assert character groups do match normal alphabet
In order to avoid us being unable to match characters which are part of
the normal US alphabet in certain weird languages, add two tests to
catch this behavior.
|
|
|
e207b2a2
|
2018-03-02T15:09:20
|
|
tests: regex: restructure setup of locales
In order to make it easier adding more locale-related tests, add a
generalized framework handling initial setup of languages as well as the
cleanup of them afterwards.
|
|
|
b055a6b5
|
2019-01-13T01:24:39
|
|
tests: regex: add test with LC_COLLATE being set
While we already have a test for `p_regexec` with `LC_CTYPE` being
modified, `regexec` also alters behavior as soon as `LC_COLLATE` is
being modified. Most importantly, `LC_COLLATE` changes the way how
ranges are interpreted to just not handling them at all. Thus, ensure
that either we use `regcomp_l` to avoid this, or that we've fallen back
to our builtin regex functionality which also behaves properly.
|
|
|
ad4ede91
|
2018-03-02T13:51:57
|
|
tests: fix p_regcomp test not checking return type
While the test asserts that the error value indcates a non-value, it is
actually never getting assigned to. Fix this.
|
|
|
31f8f82a
|
2018-03-02T12:18:59
|
|
diff_driver: detect memory allocation errors when loading diff driver
When searching for a configuration key for the diff driver, we construct
the config key by modifying a buffer and then passing it to
`git_config_get_multivar_foreach`. We do not check though whether the
modification of the buffer actually succeded, so we could in theory end
up passing the OOM buffer to the config function.
Fix that by checking return codes. While at it, switch to use
`git_buf_PUTS` to avoid repetition of the appended string to calculate
its length.
|
|
|
9ceafb57
|
2019-01-12T22:55:31
|
|
regexec: use pcre as our fallback/builtin regex
Use PCRE 8.42 as the builtin regex implementation, using its POSIX
compatibility layer. PCRE uses ASCII by default and the users locale
will not influence its behavior, so its `regcomp` implementation is
similar to `regcomp_l` with a C locale.
|
|
|
ce6d624a
|
2019-05-19T10:30:04
|
|
regex: optionally use PCRE2
Use PCRE2 and its POSIX compatibility layer if requested by the user.
Although PCRE2 is adequate for our needs, the PCRE2 POSIX layer as
installed on Debian and Ubuntu systems is broken, so we do not opt-in to
it by default to avoid breaking users on those platforms.
|
|
|
69ecdad5
|
2019-05-19T10:09:55
|
|
regex: use system PCRE if available
Attempt to locate a system-installed version of PCRE and use its POSIX
compatibility layer, if possible.
|
|
|
622166c4
|
2019-05-18T19:37:59
|
|
regex: disambiguate builtin vs system pcre
|
|
|
c6e48fef
|
2019-02-17T21:51:34
|
|
regex: allow regex selection in cmake
Users can now select which regex implementation they want to use: one of
the system `regcomp_l`, the system PCRE, the builtin PCRE or the
system's `regcomp`.
By default the system `regcomp_l` will be used if it exists, otherwise
the system PCRE will be used. If neither of those exist, then the
builtin PCRE implementation will be used.
The system's `regcomp` is not used by default due to problems with
locales.
|
|
|
09902985
|
2019-01-13T21:12:10
|
|
core::posix: skip some locale tests on win32
|
|
|
fe1fb36e
|
2019-01-13T21:10:50
|
|
win32: move type definitions for improved inclusion
Move some win32 type definitions to a standalone file so that they can
be included before other header files try to use the definitions.
|
|
|
e4b2ef87
|
2019-01-13T10:09:13
|
|
regex: don't warn on unused functions
PCRE includes compatibility functions that may go unused. Don't warn.
|
|
|
8877d7d3
|
2019-01-13T02:08:43
|
|
tests: regcomp: use proper character classes
The '[[:digit:]]' and '[[:alpha:]]' classes require double brackets, not
single.
|
|
|
ca1b07a2
|
2019-01-13T02:05:58
|
|
tests: regcomp: test that regex functions succeed
The regex functions return nonzero (not necessarily negative values) on
failure.
|
|
|
d3a440ca
|
2019-01-13T10:50:13
|
|
fuzzers: use system includes
Use the system includes (defined by libgit2) as the fuzzer includes.
The fuzzers link against internal libgit2 API and therefore need to have
the full include path that libgit2 uses.
|
|
|
02683b20
|
2019-01-12T23:06:39
|
|
regexec: prefix all regexec function calls with p_
Prefix all the calls to the the regexec family of functions with `p_`.
This allows us to swap out all the regular expression functions with our
own implementation. Move the declarations to `posix_regex.h` for
simpler inclusion.
|
|
|
c9f116f1
|
2019-05-12T22:06:00
|
|
Merge branch 'pr/5061'
|
|
|
ab27c835
|
2019-05-12T22:05:26
|
|
revwalk: update error message for clarity
|
|
|
1e3a639d
|
2019-05-12T21:54:39
|
|
Merge pull request #5065 from danielgindi/feature/win32_symlink_dir
Support symlinks for directories in win32
|
|
|
7f562f2c
|
2019-05-12T11:00:31
|
|
Merge pull request #5057 from eaigner/merge-rebase-onto-name
rebase: orig_head and onto accessors
|
|
6990a492
|
2019-05-06T11:39:51
|
|
revwalk: fix memory leak in error handling
This is not implemented and should fail, but it should also not leak. To
allow the memory debugger to find leaks and fix this one we test this.
|
|
336e98bb
|
2019-05-06T14:51:52
|
|
Moved dwFlags declaration to beginning of scope
|
|
|
37a7adb5
|
2019-05-05T07:49:09
|
|
Support symlinks for directories in win32
|
|
|
d55bb479
|
2019-04-26T15:59:49
|
|
git_revwalk_push_range: do not crash if range is missing
If someone passes just one ref (i.e. "master") and misses passing the
range we should be nice and return an error code instead of crashing.
|
|
|
604e2811
|
2019-05-02T12:09:23
|
|
Merge pull request #5063 from pks-t/pks/cmake-regcomp-fix
cmake: correctly detect if system provides `regcomp`
|
|
|
957940bf
|
2019-05-02T12:04:04
|
|
Merge pull request #5023 from ianhattendorf/fix/lock_missing_global_config
Correctly write to missing locked global config
|
|
|
ee3d71fb
|
2019-04-26T08:01:56
|
|
cmake: fix include ordering issues with bundled deps
When linking against bundled libraries, we include their header
directories by using "-isystem". The reason for that is that we
want to handle our vendored library headers specially, most
importantly to ignore warnings generated by including them. By
using "-isystem", though, we screw up the order of searched
include directories by moving those bundled dependencies towards
the end of the lookup order. Like this, chances are high that any
other specified include directory contains a file that collides
with the actual desired include file.
Fix this by not treating the bundled dependencies' include
directories as system includes. This will move them to the front
of the lookup order and thus cause them to override
system-provided headers. While this may cause the compiler to
generate additional warnings when processing bundled headers,
this is a tradeoff we should make regardless to fix builds on
systems hitting this issue.
|
|
|
13cb9f7a
|
2019-02-25T11:35:16
|
|
cmake: correctly detect if system provides `regcomp`
We assume that if we are on Win32, Amiga OS, Solaris or SunOS,
that the regcomp(3P) function cannot be provided by the system.
Thus we will in these cases always include our own, bundled regex
sources to make a regcomp implementation available. This test is
obviously very fragile, and we have seen it fail on MSYS2/MinGW
systems, which do in fact provide the regcomp symbol. The effect
is that during compilation, we will use the "regex.h" header
provided by MinGW, but use symbols provided by ourselves. This
in fact may cause subtle memory layout issues, as the structure
made available via MinGW doesn't match what our bundled code
expects.
There's one more problem with our regex detection: on the listed
platforms, we will incorrectly include the bundled regex code
even in case where the system provides regcomp_l(3), but it will
never be used for anything.
Fix the issue by improving our regcomp detection code. Instead of
relying on a fragile listing of platforms, we can just use
`CHECK_FUNCTION_EXISTS` instead. This will not in fact avoid the
header-ordering problem. But we can assume that as soon as a
system-provided "regex.h" header is provided, that
`CHECK_FUNCTION_EXISTS` will now correctly find the desired
symbol and thus not include our bundled regex code.
|
|
e44110db
|
2019-03-20T12:28:45
|
|
Correctly write to missing locked global config
Opening a default config when ~/.gitconfig doesn't exist, locking it,
and attempting to write to it causes an assertion failure.
Treat non-existent global config file content as an empty string.
|
|
|
bc5b19e6
|
2019-04-29T09:01:45
|
|
Merge pull request #4561 from pks-t/pks/downcasting
[RFC] util: introduce GIT_DOWNCAST macro
|
|
|
0c71e4cb
|
2019-04-26T10:38:02
|
|
refspec: fix transforming nested stars
When we transform a refspec with a component containing a glob, then
we simply copy over the component until the next separator from
the matching ref. E.g. if we have a ref "refs/heads/foo/bar" and
a refspec "refs/heads/*/bar:refs/remotes/origin/*/bar", we:
1. Copy over everything until hitting the glob from the <dst>
part: "refs/remotes/origin/".
2. Strip the common prefix of ref and <src> part until the glob,
which is "refs/heads/". This leaves us with a ref of "foo/bar".
3. Copy from the ref until the next "/" separator, resulting in
"refs/remotes/origin/foo".
4. Copy over the remaining part of the <dst> spec, which is
"bar": "refs/remotes/origin/foo/bar".
This worked just fine in a world where globs in refspecs were
restricted such that a globbing component may only contain a
single "*", only. But this restriction has been lifted, so that a
glob component may be nested between other characters, causing
the above algorithm to fail. Most notably the third step, where
we copy until hitting the next "/" separator, might result in a
wrong transformation. Given e.g. a ref "refs/gbranchg/head" and a
refspec "refs/g*g/head:refs/remotes/origin/*", we'd also be
copying the "g" between "branch" and "/" and end up with the
wrong transformed ref "refs/remotes/origin/branchg".
Instead of copying until the next component separator, we should
copy until we hit the pattern after the "*". So in the above
example, we'd copy until hitting the string "g/head".
|
|
|
51214b85
|
2019-04-26T10:15:49
|
|
refs: loosen restriction on wildcard "*" refspecs
In commit cd377f45c9 (refs: loosen restriction on wildcard "*"
refspecs, 2015-07-22) in git.git, the restrictions on wildcard
"*" refspecs has been loosened. While wildcards were previously
only allowed if the component is a single "*", this was changed
to also accept other patterns as part of the component.
We never adapted to that change and still reject any wildcard
patterns that aren't a single "*" only. Update our tests to
reflect the upstream change and adjust our own code accordingly.
|
|
|
9d651e05
|
2019-04-26T09:09:46
|
|
tests: network::refspecs: add missing assert when parsing refspec
|
|
|
af95615f
|
2019-04-26T08:48:17
|
|
Merge pull request #5051 from pks-t/pks/examples-ssh-auth
examples: implement SSH authentication
|
|
|
e215f475
|
2019-04-21T21:36:36
|
|
rebase: orig_head and onto accessors
The rebase struct stores fields with information about the current
rebase process, which were not accessible via a public interface.
Accessors for getting the `orig_head` and `onto` branch
names and object ids have been added.
|
|
|
b3923cf7
|
2019-04-17T13:43:52
|
|
Merge pull request #5050 from libgit2/ethomson/windows_init_traversal
git_repository_init: stop traversing at windows root
|
|
|
45f24e78
|
2019-04-12T08:54:06
|
|
git_repository_init: stop traversing at windows root
Stop traversing the filesystem at the Windows directory root. We were
calculating the filesystem root for the given directory to create, and
walking up the filesystem hierarchy. We intended to stop when the
traversal path length is equal to the root path length (ie, stopping at
the root, since no path may be shorter than the root path).
However, on Windows, the root path may be specified in two different
ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter.
`git_path_dirname_r` returns the path _without_ a trailing slash, even
for the Windows root. As a result, during traversal, we need to test
that the traversal path is _less than or equal to_ the root path length
to determine if we've hit the root to ensure that we stop when our
traversal path is `Z:` and our calculated root path was `Z:\`.
|
|
|
9c402600
|
2019-04-16T18:17:56
|
|
Merge pull request #5053 from tniessen/cf-check-array-alloc-result
config_file: check result of git_array_alloc
|
|
cc8a9892
|
2019-04-16T18:13:31
|
|
config_file: check result of git_array_alloc
git_array_alloc can return NULL if no memory is available, causing
a segmentation fault in memset. This adds GIT_ERROR_CHECK_ALLOC
similar to how other parts of the code base deal with the return
value of git_array_alloc.
|
|
b51789ac
|
2019-04-16T13:20:08
|
|
transports: make use of the `GIT_CONTAINER_OF` macro
|
|
|
2e246474
|
2019-04-16T13:19:53
|
|
refdb_fs: make use of the `GIT_CONTAINER_OF` macro
|
|
|
431601f2
|
2019-04-05T15:05:10
|
|
iterator: make use the `GIT_CONTAINER_OF` macro
|
|
|
65203b5a
|
2019-04-16T13:21:16
|
|
config_file: make use of `GIT_CONTAINER_OF` macro
|
|
|
b5f40441
|
2019-04-16T13:21:03
|
|
util: introduce GIT_CONTAINER_OF macro
In some parts of our code, we make rather heavy use of casting
structures to their respective specialized implementation. One
example is the configuration code with the general
`git_config_backend` and the specialized `diskfile_header`
structures. At some occasions, it can get confusing though with
regards to the correct inheritance structure, which led to the
recent bug fixed in 2424e64c4 (config: harden our use of the
backend objects a bit, 2018-02-28).
Object-oriented programming in C is hard, but we can at least try
to have some checks when it comes to casting around stuff. Thus,
this commit introduces a `GIT_CONTAINER_OF` macro, which accepts
as parameters the pointer that is to be casted, the pointer it
should be cast to as well as the member inside of the target
structure that is the containing structure. This macro then tries
hard to detect mis-casts:
- It checks whether the source and target pointers are of the
same type. This requires support by the compiler, as it makes
use of the builtin `__builtin_types_compatible_p`.
- It checks whether the embedded member of the target structure
is the first member. In order to make this a compile-time
constant, the compiler-provided `__builtin_offsetof` is being
used for this.
- It ties these two checks together by the compiler-builtin
`__builtin_choose_expr`. Based on whether the previous two
checks evaluate to `true`, the compiler will either compile in
the correct cast, or it will output `(void)0`. The second case
results in a compiler error, resulting in a compile-time check
for wrong casts.
The only downside to this is that it relies heavily on
compiler-specific extensions. As both GCC and Clang support these
features, only define this macro like explained above in case
`__GNUC__` is set (Clang also defines `__GNUC__`). If the
compiler is not Clang or GCC, just go with a simple cast without
any additional checks.
|
|
|
ed959ca2
|
2019-04-16T12:36:24
|
|
Merge pull request #5027 from ddevault/master
patch_parse.c: Handle CRLF in parse_header_start
|
|
|
172786ec
|
2019-04-16T12:03:20
|
|
examples: use username provided via URL
The credentials callback may be passed a username in case where
the URL already includes the expected username. As we usually
cannot use a different username in such context, we should use
that one if provided and not ask the user for a diferent
username.
|
|
|
611fbe4f
|
2019-04-16T12:02:20
|
|
examples: implement SSH key credentials
Implement SSH key credentials. This allows users to use the SSH
transport with the lg2 example code.
|
|
|
d9351c65
|
2019-04-16T11:05:37
|
|
examples: implement SSH key credentials
Implement SSH key credentials. This allows users to use the SSH
transport with the lg2 example code.
|
|
|
e9aa8479
|
2019-04-16T10:52:47
|
|
examples: support plain username credentials
Implement plain username credential types. These type of
credentials might be asked for e.g. as some kind of
pre-authentication step, before the actual credentials are
passed.
|
|
|
635ec366
|
2019-04-16T10:51:43
|
|
examples: honor allowed credential types when prompting user
Credential callback are being passed a bitset that indicates
which credential types are allowed in the current context. In our
examples code, we completely ignore that field and always return
username/password credentials, which doesn't necessarily make
sense e.g. when only SSH keys are allowed.
Refactor the code and only return username/password credentials
in the case where `USERPASS_PLAINTEXT` credentials are allowed.
Otherwise, return a positive error code to indicate that no
credentials could be acquired.
|
|
|
b106620d
|
2019-04-16T10:56:18
|
|
examples: move MSVC compatibility macros into common header
We currently have two locations in our examples where we define
the same compatibility wrappers for MSVC. Move them into
"common.h" to avoid duplication and make them available to other
examples.
|
|
|
d1cfd79a
|
2019-04-08T08:20:35
|
|
Merge pull request #5045 from cheese1/patch-1
fix typo
|
|
67562b23
|
2019-04-07T16:45:45
|
|
fix typo
|
|
|
c4cd69b2
|
2019-04-07T19:10:16
|
|
Merge pull request #5039 from libgit2/ethomson/win32_hash
sha1: don't inline `git_hash_global_init` for win32
|
|
|
5a190ad3
|
2019-04-07T19:07:42
|
|
Merge pull request #5040 from pks-t/pks/ignore-treat-dirpaths-as-dir
ignore: treat paths with trailing "/" as directories
|
|
30c06b60
|
2019-03-22T23:56:10
|
|
patch_parse.c: Handle CRLF in parse_header_start
|
|
|
9d117e20
|
2019-04-05T10:22:46
|
|
ignore: treat paths with trailing "/" as directories
The function `git_ignore_path_is_ignored` is there to test the
ignore status of paths that need not necessarily exist inside of
a repository. This has the implication that for a given path, we
cannot always decide whether it references a directory or a file,
and we need to distinguish those cases because ignore rules may
treat those differently. E.g. given the following gitignore file:
*
!/**/
we'd only want to unignore directories, while keeping files
ignored. But still, calling `git_ignore_path_is_ignored("dir/")`
will say that this directory is ignored because it treats "dir/"
as a file path.
As said, the `is_ignored` function cannot always decide whether
the given path is a file or directory, and thus it may produce
wrong results in some cases. While this is unfixable in the
general case, we can do better when we are being passed a path
name with a trailing path separator (e.g. "dir/") and always
treat them as directories.
|
|
|
aeea1c46
|
2019-04-04T15:06:44
|
|
Merge pull request #4874 from tiennou/test/4615
Test that largefiles can be read through the tree API
|
|
|
80db2043
|
2019-04-04T14:16:44
|
|
Merge pull request #5034 from pks-t/pks/symlinked-user-config
Tests for symlinked user config
|
|
|
6bcb7357
|
2019-04-04T14:04:59
|
|
Merge pull request #5035 from pks-t/pks/diff-with-space-in-filenames
patch_parse: fix parsing addition/deletion of file with space
|
|
|
fb7614c0
|
2019-04-04T13:51:52
|
|
tests: test largefiles on win32
|
|
|
18e836cb
|
2019-04-04T10:55:38
|
|
Merge pull request #5018 from romkatv/strings
Optimize string comparisons
|
|
|
e5aecaf6
|
2019-04-04T18:45:30
|
|
sha1: don't inline `git_hash_global_init` for win32
Users of the Win32 hash cannot be inlined, as it uses a static struct.
Don't inline it, but continue to declare the function in the header.
|
|
30a56ba6
|
2019-03-14T14:54:47
|
|
optimize string comparisons
|
|
|
9aa049d4
|
2019-03-29T13:28:59
|
|
Merge pull request #5020 from implausible/fix/gitignore-negation
Negation of subdir ignore causes other subdirs to be unignored
|
|
|
8cf3fd93
|
2019-03-29T11:23:29
|
|
tests: config: assure that we can read symlinked global configuration
According to reports, libgit2 is unable to read a global configuration
file that is simply a symlink to the real configuration. Write a
(succeeding) test that shows that libgit2 _is_ correctly able to do so.
|
|
|
b3ba2e71
|
2019-03-29T11:15:26
|
|
tests: config: verify that the global config is actually readable
While we do verify that we are able to open the global ".gitconfig" file
in config::global::open_global, we never verify that we it is in fact
readable. Do so by writing the global configuration file and verifying
that reading from it produces the expected values.
|
|
|
25c085e6
|
2019-03-29T11:41:42
|
|
tests: repo: verify that we can open repos with symlinked global config
We've got reports that users are unable to open repos when their global
configuration ("~/.gitconfig") is a symlink. Add a test to verify that
we are in fact able to do so as expected.
|
|
|
9d65360b
|
2019-03-29T12:30:37
|
|
tests: diff: test parsing diffs with a new file with spaces in its path
Add a test that verifies that we are able to parse patches which add a
new file that has spaces in its path.
|
|
|
b3497344
|
2019-03-29T12:15:20
|
|
patch_parse: fix parsing addition/deletion of file with space
The diff header format is a strange beast in that it is inherently
unparseable in an unambiguous way. While parsing
a/file.txt b/file.txt
is obvious and trivially doable, parsing a diff header of
a/file b/file ab.txt b/file b/file ab.txt
is not (but in fact valid and created by git.git).
Due to that, we have relaxed our diff header parser in commit 80226b5f6
(patch_parse: allow parsing ambiguous patch headers, 2017-09-22), so
that we started to bail out when seeing diff headers with spaces in
their file names. Instead, we try to use the "---" and "+++" lines,
which are unambiguous.
In some cases, though, we neither have a useable file name from the
header nor from the "---" or "+++" lines. This is the case when we have
a deletion or addition of a file with spaces: the header is unparseable
and the other lines will simply show "/dev/null". This trips our parsing
logic when we try to extract the prefix (the "a/" part) that is being
used in the path line, where we unconditionally try to dereference a
NULL pointer in such a scenario.
We can fix this by simply not trying to parse the prefix in cases where
we have no useable path name. That'd leave the parsed patch without
either `old_prefix` or `new_prefix` populated. But in fact such cases
are already handled by users of the patch object, which simply opt to
use the default prefixes in that case.
|
|
|
131cd9b1
|
2019-03-29T11:58:50
|
|
patch_parse: improve formatting
|
|
|
5f188c48
|
2019-03-29T11:52:39
|
|
Merge pull request #5024 from stewid/xdiff-fix-typo
xdiff: fix typo
|
|
|
fa4505e6
|
2019-03-29T11:30:29
|
|
tests: config: make sure to clean up after each test
The config::global test suite creates various different directories and
files which are being populated with pretend-global files.
Unfortunately, the tests do not clean up after themselves, which may
cause subsequent tests to fail due to cruft left behind.
Fix this by always removing created directories and their contents.
|
|
|
675251d1
|
2019-03-28T20:35:17
|
|
Merge pull request #5032 from eaigner/checkout-force-safe-docfix
docs: clarify relation of safe and forced checkout strategy
|
|
|
bbba4805
|
2019-03-25T20:45:58
|
|
docs: clarify relation of safe and forced checkout strategy
|
|
|
7f1ba196
|
2019-03-24T17:41:24
|
|
Merge pull request #5026 from tenderlove/define-hash-global-init-consnstently
Each hash implementation should define `git_hash_global_init`
|
|
be9a386c
|
2019-03-22T17:04:32
|
|
Each hash implementation should define `git_hash_global_init`
This means the forward declaration isn't necessary. The forward
declaration can cause compilation errors as it conflicts with the
`GIT_INLINE` declaration (the signatures are different).
|