| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Provide a mechanism for the client library to report a unique
error class. This will not be used by libgit2 directly.
|
| |
|
|
|
|
| |
Introduce a helper method to quote a string in a shellsafe manner. This
wraps the entire buffer in single quotes, escaping single-quotes and
exclamation points.
|
| |
|
|
| |
Add a function to add a search/replaced string to a git_buf.
|
| | |
|
| | |
|
| |
|
|
|
| |
SSH paths come in a variety of formats, either URLs (ssh://user@host/path)
or SCP style (user@host:path). Provide a mechanism to parse them.
|
| | |
|
| |
|
|
| |
Provide functions to search through string arrays.
|
| |
|
|
|
| |
Provide a helper function to copy a number of strings from the source to
the target.
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Set up a framework for subcommands, and introduce the first, "help".
Help will display the commands available, and information about the
help command itself.
Commands are expected to provide their own usage and help information,
which the help command will proxy to when necessary.
|
| |
|
|
|
|
| |
Our options parsing system can also be used as the basis for displaying
command-line usage. Add usage information, using knowledge of the
console (if we're attached to one) for wrapping nicely.
|
| |
|
|
|
|
|
| |
As we consume parts of the libgit2 utility functions (like `git_buf`),
we will inevitably need to allocate. Since we re-use the libgit2
allocation functions - but linked into our application - we'll need
to configure our allocation strategy ahead of time.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a command-line interface for libgit2. The goal is to be
git-compatible, so that:
1. By creating a git client ourselves, we can understand the needs of
git clients and produce a common "middleware" for commonly-used
pieces of client functionality. For example: interacting with
other command-line tools, like filter drivers or merge drivers.
This can assist other git clients.
2. We can benefit from git's unit tests, running their test suite
against our own CLI to ensure correct behavior.
3. We can easily benchmark ourselves against git to understand where we
are poorly performing, by running identical commands between git and
ourselves.
4. We can easily A/B test ourselves against git, at least for read-only
operations, which will ensure that we are producing identical output.
This commit introduces a simple infrastructure for the CLI.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Introduce libgit2client, a client "middleware" library. This is an
experimental set of utility functions and classes for client software
that builds on top of libgit2.
This library might contain - for example - code that invokes filters or
other tools. This is incredibly useful to share and reuse among
consumers but should be excluded from libgit2 itself. Users may,
understandably, not want code that executes arbitrary other commands in
libgit2 itself.
|
| |
|
|
|
| |
Put the common clar test function into the tests/CMakeLists.txt for
reusability.
|
| |
|
|
|
|
| |
Other subsystems (like libgit2client) likely want to add testing.
Move clar into its own directory so that it can be reused and not
duplicated.
|
| |
|
|
|
|
|
|
| |
The test tree should - ideally - match the source tree. The libgit2
specific tests should move into tests/libgit2.
The name of the resulting test binary is now 'libgit2_tests' for ease of
consumption of new contributors.
|
| |
|
|
|
|
| |
The functions exported by libgit2 should stay in the libgit2 directory.
By putting them in `util`, they'll be further exported by any other tool
that uses the util library.
|
| |
|
|
|
|
|
| |
Add a new source directory, `util`, that contains utility functions like
buffers, vectors, etc, that that are general purpose and not necessarily
part of libgit2 itself. These utility functions can be used by
additional projects.
|
| |
|
|
| |
Adding an additional hierarchy supports additional projects.
|
| |
|
|
|
|
|
| |
Provide a more abstract mechanism for system components to register for
initialization and shutdown of a "runtime". This abstracts the init and
suhtdown logic out of `git_libgit2_init` so that it can be re-used
across other components (eg, libgit2client, cli).
|
| |
|
|
|
|
| |
We want to store a pointer to emulate `pthread_exit` on Windows. Do
this within the threading infrastructure so that it could potentially be
re-used outside of the context of libgit2 itself.
|
| |
|
|
| |
We were never properly testing git_thread_exit. Do so.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Our "global initialization" has accumulated some debris over the years.
It was previously responsible for both running the various global
initializers (that set up various subsystems) _and_ setting up the
"global state", which is actually the thread-local state for things
like error reporting.
Separate the thread local state out into "tlsdata". Use the normal
subsystem initialization functions that we already have to set it up.
This makes both the global initialization system and the tlsdata system
simpler to reason about.
|
| |
|
|
|
|
| |
Move the mwindow mutex into the mwindow code itself, initializing it in
the mwindow global initialization function instead of in the global
initializer.
|
| |
|
|
|
| |
Move the settings global data teardown into its own separate function,
instead of intermingled with the global state.
|
| |
|
|
|
| |
The win32 debug stack handling is not special; it should use the same
initialization functionality that everybody else does.
|
| |
|
|
|
| |
Instead of treating win32 thread initialization specially in the win32
git_libgit2_init function, add a git_global_threads_init function.
|
| |
|
|
|
|
| |
The tracing helper for clar uses git_trace() directly. Let's keep this
private, and instead use `git_buf_printf` to give us the message that we
want and then call the trace helper that we set up directly.
|
| | |
|
| |
|
|
|
|
|
|
| |
Make `git_error_set` public so that the forthcoming utility library can
take advantage of it. Although this is not dangerous to export, it is
not up to our general standards of public API since it cannot return an
error code, for instance. Therefore, we discourage its use in a comment
and by hiding it in a `sys` include directory.
|
| |
|
|
|
| |
We don't call any internal functions in the test; we don't need to
include `../src/diff.h`.
|
| |
|
|
|
|
| |
`git_strarray` is a public-facing type. Chagne
`git_buf_text_common_prefix` to not use it, and just take an array of
strings instead.
|
| |
|
|
|
| |
Make path.[ch] contain pure utility functions that do not know about
public-facing libgit2 objects, including `git_repository`.
|
| |
|
|
|
| |
Provide the system error message functionality (strerror or the string
handling for GetLastError on Windows) into a utility class.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `git_buf` type is now no longer a publicly available structure, and
the `git_buf` family of functions are no longer exported.
The deprecation layer adds a typedef for `git_buf` (as `git_userbuf`)
and macros that define `git_buf` functions as `git_userbuf` functions.
This provides API (but not ABI) compatibility with libgit2 1.0's buffer
functionality.
Within libgit2 itself, we take care to avoid including those deprecated
typedefs and macros, since we want to continue using the `git_buf` type
and functions unmodified. Therefore, a `GIT_DEPRECATE_BUF` guard now
wraps the buffer deprecation layer. libgit2 will define that.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
