| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Including the `include/git2` build path is a seemingly unnecessary
oversight to include the generated `experimental.h` file.
|
| |\
| |
| | |
SHA256: more SHA256 support
|
| | |
| |
| |
| |
| | |
This is much of the plumbing for the object database to support SHA256,
and for objects to be able to parse SHA256 versions of themselves.
|
| |\ \
| |/
|/| |
Fix build failure with -DEMBED_SSH_PATH
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
The experimental function signature is only available when
`GIT_EXPERIMENTAL_SHA256` is enabled.
|
| |
|
|
|
|
|
|
|
|
| |
libgit2 can be built with optional, experimental sha256 support. This
allows consumers to begin testing and providing feedback for our sha256
support while we continue to develop it, and allows us to make API
breaking changes while we iterate on a final sha256 implementation.
The results will be `git2-experimental.dll` and installed as
`git2-experimental.h` to avoid confusion with a production libgit2.
|
| |
|
|
|
| |
Linux has a /usr/include/features.h, which gets confusing; update this
to `git2_features.h` and move it into the `util` directory.
|
| |
|
|
|
| |
The git_odb_hash helper functions should not assume SHA1, and instead
should be given the oid type that they're producing.
|
| |
|
|
|
| |
Avoid too much flashing on the console with updates about throughput.
Only update throughput once a second.
|
| | |
|
| | |
|
| |
|
|
| |
Provide a mechanism to add a signal handler for Unix or Win32.
|
| |
|
|
|
|
| |
Provide a class that will display progress information to the console.
Initially, it contains callbacks for fetch progress and checkout
progress.
|
| | |
|
| |
|
|
| |
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.
|
