| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was pulled over from git.git, and is an experiment in
making binary-searching lists of sha1s faster. It was never
compiled by default (nor was it used upstream by default
without a special environment variable).
Unfortunately, it is actually slower in practice, and
upstream is planning to drop it in
git/git@f1068efefe6dd3beaa89484db5e2db730b094e0b (which has
some timing results). It's worth doing the same here for
simplicity.
|
| |\
| |
| | |
patch_generate: represent buffers as void pointers
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Pointers to general data should usually be used as a void pointer such
that it is possible to hand in variables of a different pointer type
without the need to cast. This is the same when creating patches from
buffers, where the buffers may contain arbitrary data. Instead of
requiring the caller to care whether his buffer is e.g. `char *` or
`unsigned char *`, we should instead just accept a `void *`. This is
also consistent in how we tread other types like for example `git_blob`,
which also just has a void pointer as its raw contents.
|
| |\ \
| | |
| | | |
Remove unused 'sys/remote.h' header
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The repository URL is duplicated several times and can be de-duplicated
like this. Furthermore, exchange the static refspec variable with a
define to reduce BSS size.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Right now it is only possible to create remotes from a repository. While
this is probably the most common use-case, there are commands which make
sense even without a repository, e.g. the equivalence of `git
ls-remote`. Add a new function `git_remote_create_detached`, which
simply accepts a URL.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are only few actions which actually make sense for a detached
remote, like e.g. `git_remote_ls`, `git_remote_prune`. For all the other
actions, we have to report an error when the remote has no repository
attached to it. This commit does so and implements some tests.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current error message when connecting to a remote when no URL is set
is missing information on whether it is missing a fetch or push URL.
Furthermore, it results in undefined behavior when using a remote
without name. Fix both issues.
|
| |\ \ \
| | | |
| | | | |
tests: rebase::submodule: verify initialization method calls
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some return codes for functions which may fail are not being checked in
`test_rebase_submodule__initialize`. This may lead us to not notice
errors when initializing the environment and would possibly result in
either memory corruption or segfaults as soon as any of the
initialization steps fails. Fix this by wrapping these function calls
into `cl_git_pass`.
|
| |\ \ \
| | | |
| | | | |
tests: rewrite rebase-submodule .gitmodule file
|
| | | | | |
|
| | | | |
| | | |
| | | | |
Fixes #4274
|
| |\ \ \ \
| | | | |
| | | | | |
tsort: remove idempotent conditional assignment
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The conditional `run < minrun` can never be true directly after
assigning `run = minrun`. Remove it to avoid confusion.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Build with patched libcurl
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Ubuntu trusty has a bug in curl when using NTLM credentials in a proxy,
dereferencing a null pointer and causing segmentation faults. Use a
custom-patched version of libcurl that avoids this issue.
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
win32: provide fast-path for retrying filesystem operations
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When using the `do_with_retries` macro for retrying filesystem
operations in the posix emulation layer, allow the remediation function
to return `GIT_RETRY`, meaning that the error was believed to be
remediated, and the operation should be retried immediately, without
a sleep.
This is a slightly more general solution to the problem fixed in #4312.
|
| | | | | | |
|
| | |/ / /
| | | |
| | | | |
Fixed an issue where the retry logic on p_unlink sleeps before it tries setting a file to write mode causing unnecessary slowdown.
|
| |\ \ \ \
| | | | |
| | | | | |
Configuration file fixes with includes
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Modifying variables pulled in by an included file currently succeeds,
but it doesn't actually do what one would expect, as refreshing the
configuration will cause the values to reappear. As we are currently not
really able to support this use case, we will instead just return an
error for deleting and setting variables which were included via an
include.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Right now, we have multiple call sites which initialize a `reader`
structure. As the structure is only actually used inside of
`config_read`, we can instead just move the reader inside of the
`config_read` function. Instead, we can just pass in the configuration
file into `config_read`, which eases code readability.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Currently, we only re-parse the top-level configuration file when it has
changed itself. This can cause problems when an include is changed, as
we were not updating all values correctly.
Instead of conditionally reparsing only refreshed files, the logic
becomes much clearer and easier to follow if we always re-parse the
top-level configuration file when either the file itself or one of its
included configuration files has changed on disk. This commit implements
this logic.
Note that this might impact performance in some cases, as we need to
re-read all configuration files whenever any of the included files
changed. It could increase performance to just re-parse include files
which have actually changed, but this would compromise maintainability
of the code without much gain. The only case where we will gain anything
is when we actually use includes and when only these includes are
updated, which will probably be quite an unusual scenario to actually be
worthwhile to optimize.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The backend passed to `config_read` is never actually used anymore, so
we can remove it from the function and the `parse_data` structure.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously, the callbacks passed to `config_parse` got the reader via a
pointer to a pointer. This allowed the callbacks to update the callers
`reader` variable when the array holding it has been reallocated. As the
array is no longer present, we can simply the code by making the reader
a simple pointer.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Current code for configuration files uses the `reader` structure to
parse configuration files and store additional metadata like the file's
path and checksum. These structures are stored within an array in the
backend itself, which causes multiple problems.
First, it does not make sense to keep around the file's contents with
the backend itself. While this data is usually free'd before being added
to the backend, this brings along somewhat intricate lifecycle problems.
A better solution would be to store only the file paths as well as the
checksum of the currently parsed content only.
The second problem is that the `reader` structures are stored inside an
array. When re-parsing configuration files due to changed contents, we
may cause this array to be reallocated, requiring us to update pointers
hold by callers. Furthermore, we do not keep track of includes which
are already associated to a reader inside of this array. This causes us
to add readers multiple times to the backend, e.g. in the scenario of
refreshing configurations.
This commit fixes these shortcomings. We introduce a split between the
parsing data and the configuration file's metadata. The `reader` will
now only hold the file's contents and the parser state and the new
`config_file` structure holds the file's path and checksum. Furthermore,
the new structure is a recursive structure in that it will also hold
references to the files it directly includes. The diskfile is changed to
only store the top-level configuration file.
These changes allow us further refactorings and greatly simplify
understanding the code.
|
| | |/ / / |
|
| |\ \ \ \
| |/ / /
|/| | | |
Patch ID calculation
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The upstream git project provides the ability to calculate a so-called
patch ID. Quoting from git-patch-id(1):
A "patch ID" is nothing but a sum of SHA-1 of the file diffs
associated with a patch, with whitespace and line numbers ignored."
Patch IDs can be used to identify two patches which are probably the
same thing, e.g. when a patch has been cherry-picked to another branch.
This commit implements a new function `git_diff_patchid`, which gets a
patch and derives an OID from the diff. Note the different terminology
here: a patch in libgit2 are the differences in a single file and a diff
can contain multiple patches for different files. The implementation
matches the upstream implementation and should derive the same OID for
the same diff. In fact, some code has been directly derived from the
upstream implementation.
The upstream implementation has two different modes to calculate patch
IDs, which is the stable and unstable mode. The old way of calculating
the patch IDs was unstable in a sense that a different ordering the
diffs was leading to different results. This oversight was fixed in git
1.9, but as git tries hard to never break existing workflows, the old
and unstable way is still default. The newer and stable way does not
care for ordering of the diff hunks, and in fact it is the mode that
should probably be used today. So right now, we only implement the
stable way of generating the patch ID.
|
| |\ \ \ \
| | | | |
| | | | | |
signature: don't leave a dangling pointer to the strings on parse failure
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If the signature is invalid but we detect that after allocating the strings, we
free them. We however leave that pointer dangling in the structure the caller
gave us, which can lead to double-free.
Set these pointers to `NULL` after freeing their memory to avoid this.
|
| |\ \ \ \
| |_|_|/
|/| | | |
git_reset_*: pass parameters as const pointers
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | | |
tests: config: fix missing declaration causing error
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On systems where we pull in our distributed version of the regex
library, all tests in config::readonly fail. This error is actually
quite interesting: the test suite is unable to find the declaration of
`git_path_exists` and assumes it has a signature of `int
git_path_exists(const char *)`. But actually, it has a `bool` return
value. Due to this confusion, some wrong conversion is done by the
compiler and the `cl_assert(!git_path_exists("file"))` checks
erroneously fail, even when the function does in fact return the correct
value.
The error is actually introduced by 56893bb9a (cmake: consistently use
TARGET_INCLUDE_DIRECTORIES if available, 2017-06-28), unfortunately
introduced by myself. Due to the delayed addition of include
directories, we will now find the "config.h" header inside of the
"deps/regex" directory instead of inside the "src/" directory, where it
should be. As such, we are missing definitions for the
`git_config_file__ondisk` and `git_path_exists` symbols.
The correct fix here would be to fix the order in which include search
directories are added. But due to the current restructuring of
CMakeBuild.txt, I'm refraining from doing so and delay the proper fix a
bit. Instead, we paper over the issue by explicitly including "path.h"
to fix its prototype. This ignores the issue that
`git_config_file__ondisk` is undeclared, as its signature is correctly
identified by the compiler.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of using INCLUDE_DIRECTORIES again for the libgit2_clar test
suite, we should just be using TARGET_INCLUDE_DIRECTORIES again if the
CMake version is greater than 2.8.11.
|
| | | | |
| | | |
| | | |
| | | | |
Apply `target_include_directories` when CMAKE_VERSION >= 2.8.12
|
| |\ \ \ \
| |/ / /
|/| | | |
Convert port with htons() in p_getaddrinfo()
|
| | |/ /
| | |
| | |
| | | |
`sin_port` should be in network byte order.
|
| |\ \ \
| | | |
| | | | |
Out of tree builds
|
