| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Introduce a simple command that emulates `git hash-object`.
|
| | |
|
| | |
|
| |
|
|
| |
Introduce a simple command that emulates `git cat-file`.
|
| |
|
|
|
|
| |
Support `help <command>` by re-invoking the command itself with the
`--help` argument. This allows us to keep the help logic with the
commands itself.
|
| |
|
|
|
|
|
| |
Add a framework for commands to be defined, and add our first one,
"help". When `git2_cli help` is run, the `cmd_help` function will be
invoked with the remaining command line arguments. This allows users to
invoke `git2_cli help foo` to get information about the `foo` subcommand.
|
| |
|
|
|
|
|
| |
Our argument parser (https://github.com/ethomson/adopt) includes a
function to print a usage message based on the allowed options. Omit
this and use a cutom function that understands that we have subcommands
("checkout", "revert", etc) that each have their own options.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a command-line interface for libgit2. The goal is for it to
be git-compatible.
1. The libgit2 developers can more easily dogfood libgit2 to find bugs,
and performance issues.
2. There is growing usage of libgit2's examples as a client; libgit2's
examples should be exactly that - simple code samples that illustrate
libgit2's usage. This satisfies that need directly.
3. By producing a client ourselves, we can better understand the needs
of client creators, possibly producing a shared "middleware" for
commonly-used pieces of client functionality like interacting with
external tools.
4. Since git is the reference implementation, we may be able to benefit
from git's unit tests, running their test suite against our CLI to
ensure correct behavior.
This commit introduces a simple infrastructure for the CLI.
The CLI is currently links libgit2 statically; this is because the
utility layer is required for libgit2 _but_ shares the error state
handling with libgit2 itself. There's no obviously good solution
here without introducing annoying indirection or more complexity.
Until we can untangle that dependency, this is a good step forward.
In the meantime, we link the libgit2 object files, but we do not include
the (private) libgit2 headers. This constrains the CLI to the public
libgit2 interfaces.
|
| |
|
|
|
|
| |
Like we want to separate libgit2 and utility source code, we want to
separate libgit2 and utility tests. Start by moving all the tests into
libgit2.
|
| |
|
|
|
| |
The `git2internal` target is actually the git library; call it such so
that IDE users have visibility into it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Instead of simply including the utility files directly, make them a
cmake object library for easy reusability between other projects within
libgit2.
Now the top-level `src` is responsible for platform selection, while the
next-level `libgit2` and `util` configurations are responsible for
identifying what objects they include.
|
| | |
|
| |
|
|
|
| |
The `git_error_set` function is useful for callers who implement
backends and advanced callbacks. Expose it.
|
| |
|
|
|
| |
Newer gcc is complaining about `object` being potentially not
initialized; initialize it.
|
| |\
| |
| | |
win32: `find_system_dirs` does not return `GIT_ENOTFOUND`
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Allow for no Git for Windows installation. When there is no GfW found
in the path or registry, `git_win32__find_system_dirs` would return a
`GIT_ENOTFOUND`. Callers were not expecting this. Since this is no
error, we simply return `0` so that callers can move on with their
lives.
|
| |/
|
|
|
|
|
|
| |
We use `git_error_set_after_callback_function` to determine whether
`update_tips` returned an error but do not store its return value making us
think it always returns 0.
Fix it by adding the common patter of storing it inside the `if` when calling it.
|
| |\
| |
| | |
meta: update version number to v1.5.0-alpha
|
| | | |
|
| |/
|
|
|
|
|
|
| |
We've added a lovely abstraction layer in xdiff so that it can call our
allocation functions. But it also needs to call our free functions. We
missed some `free` calls in `xmerge.c`. Update them to use `xdl_free`.
Without this, we will pass a pointer allocated with a custom allocator
to the system free function. :bomb:
|
| |\
| |
| | |
merge: fix overlap between GIT_MERGE_FILE_FAVOR__CONFLICTED and GIT_MERGE_FILE_SIMPLIFY_ALNUM
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We made the flags that enable recursive merge internal, on the
assumption that nobody would want them and they're hard to reason about.
(Giving people an option that nobody wants is just extra noise.)
However, it made it hard for _us_ to reason about. There's no good
reason to keep it private, let's just make it public and push that
cognitive load onto our poor users. But they should expect it, they're
dealing with git, after all.
|
| | |
| |
| |
| |
| | |
Allocate flags in git_merge_flag_t and git_merge_file_flag_t
for internal usage to prevent accidental double allocation.
|
| | |
| |
| |
| |
| |
| |
| | |
GIT_MERGE_FILE__CONFLICTED
This is to avoid a possible problem where the value is set to the
same as GIT_MERGE_FILE_SIMPLIFY_ALNUM in git_merge_file_flag_t
|
| |\ \
| | |
| | | |
diff_file: fix crash if size of diffed file changes in workdir
|
| | | |
| | |
| | |
| | |
| | | |
When we know that we know a file's size, and the file's size changes,
fail.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we know the file size (because we're producing it from a working
directory iterator, or an index with an up-to-date cache) then set a
flag indicating as such. This removes the ambiguity about a 0 file
size, which could indicate that a file exists and is 0 bytes, or that we
haven't read it yet.
|
| | | |
| | |
| | |
| | |
| | | |
Move the empty tree ID into a global space so that it can be generally
used.
|
| | | |
| | |
| | |
| | |
| | | |
Skip new_file_size non-zero test, custom error message if file changed in workdir
Co-authored-by: Edward Thomson <ethomson@github.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"diff_file_content_load_workdir_file()" maps a file from the workdir
into memory. It uses git_diff_file.size to determine the size of the
memory mapping.
If this value goes stale, the mmaped area would be sized incorrectly.
This could occur if an external program changes the contents of the
file after libgit2 had cached its size. This used to segfault if the
file becomes smaller (mmaped area too large).
This patch causes diff_file_content_load_workdir_file to fail without
crashing if it detects that the file size has changed.
|
| |\ \ \
| |/ /
|/| | |
mktmp: improve our temp file creation
|
| | | |
| | |
| | |
| | |
| | |
| | | |
We have our own temporary file creation function now in
`git_futils_mktmp`, remove the others since they may be terrible on some
platforms.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
`mktemp` on mingw is exceedingly deficient, using a single monotonically
increasing alphabetic character and the pid. We need to use our own
random number generator for temporary filenames.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Introduce `git_rand`, a PRNG based on xoroshiro256**, a fast,
all-purpose pseudo-random number generator: https://prng.di.unimi.it
The PRNG will be seeded by the system's entropy store when possible,
falling back to current time and system data (pid, uptime, etc).
Inspiration for this was taken from libressl, but since our PRNG is
not used for cryptographic purposes (and indeed currently only generates
a unique temp file name that is written in a protected directory),
this should be more than sufficient.
Our implementation of xoroshiro256** was taken almost strictly from
the original author's sources, but was tested against PractRand to
ensure that there were no foolish mistranslations:
```
RNG_test using PractRand version 0.94
RNG = RNG_stdin64, seed = unknown
test set = core, folding = standard (64 bit)
rng=RNG_stdin64, seed=unknown
length= 256 megabytes (2^28 bytes), time= 2.9 seconds
no anomalies in 210 test result(s)
rng=RNG_stdin64, seed=unknown
length= 512 megabytes (2^29 bytes), time= 6.2 seconds
no anomalies in 226 test result(s)
rng=RNG_stdin64, seed=unknown
length= 1 gigabyte (2^30 bytes), time= 12.7 seconds
no anomalies in 243 test result(s)
rng=RNG_stdin64, seed=unknown
length= 2 gigabytes (2^31 bytes), time= 25.4 seconds
no anomalies in 261 test result(s)
rng=RNG_stdin64, seed=unknown
length= 4 gigabytes (2^32 bytes), time= 50.6 seconds
no anomalies in 277 test result(s)
rng=RNG_stdin64, seed=unknown
length= 8 gigabytes (2^33 bytes), time= 104 seconds
no anomalies in 294 test result(s)
```
|
| |\ \ \
| |/ /
|/| | |
Fetch by object id
|
| | | | |
|
| | | | |
|
| | | | |
|
