| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| | | |
| | | | |
Skip UTF8 BOM in ignore files
|
| | |/ / |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
`z` library (libgit2/#5079).
|
| |/ / |
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
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.
|
| | |/
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | | |
Support symlinks for directories in win32
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
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.
|
| |\ \
| | |
| | | |
cmake: correctly detect if system provides `regcomp`
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ /
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/| |
[RFC] util: introduce GIT_DOWNCAST 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.
|
| |\ \
| | |
| | | |
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:\`.
|
| | |/
|/|
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/| |
patch_parse.c: Handle CRLF in parse_header_start
|
| | | |
|
| |\ \
| | |
| | | |
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.
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | | |
Test that largefiles can be read through the tree API
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On macOS, fcntl(..., F_PREALLOCATE, ...) will only succeed when followed
by an ftruncate(), even when it reports success.
However, that syscall will fail when the file already exists. Thus, we
must ignore the error code and simply let ftruncate extend the size of
the file itself (albeit slowly).
By calling ftruncate, we also need to prevent against file shrinkage,
for compatibility with posix_ftruncate, which will only extend files,
never shrink them.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Emulate `p_fallocate` on Windows by seeking beyond the end of the file
and setting the size to the current seek position.
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
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.
|
| | | | | |
|
| |\ \ \ \
| |_|_|/
|/| | | |
Optimize string comparisons
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | | |
Negation of subdir ignore causes other subdirs to be unignored
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Matching on the prefix of a negated pattern was triggering false
negatives on siblings of that pattern. e.g.
Given the .gitignore:
dir/*
!dir/sub1/sub2/**
The path `dir/a.text` would not be ignored.
|
| |\ \ \
| | | |
| | | | |
xdiff: fix typo
|
| | |/ / |
|
