Make `GIT_CHECKOUT_SAFE` the default. `NONE` is never what the user
wants _by default_; people expect checkout to, well, check things out.
Instead, it should be an opt-in "dry run" mode.
This removes some odd code in internal callers of `checkout` that takes
a `git_checkout_options` and updates the mode to `SAFE`. This is now
unnecessary since everything has better defaults.
This PR ensures and enforces C90 conformance for all files C, including tests.
* Modify CMakeLists.txt to mandate C90 conformance (for better compiler compatibility)
* Update deps/ntlmclient/utf8.h to latest version
* Modify two tests and one header to use C comments instead of C++ comments
Unlike existing functions, this produces a _thin_ packfile by
making use of the fact that only new objects appear in the
mempack Object Database.
A thin packfile only contains certain objects, but not its whole
closure of references. This makes it suitable for efficiently
writing sets of new objects to a local repository, by avoiding
many small I/O operations.
This relies on write_pack (e.g. git_packbuilder_write_buf) to
implement the "recency order" optimization step.
Basic measurements comparing against the writing of individual
objects show a speedup during when writing large amounts of
content on machines with comparatively slow I/O operations,
and little to no change on machines with fast I/O operations.
Specifically, forward errors from packbuilder->progress_cb
This allows the callback to gracefully terminate long-running
operations when the application is interrupted.
Interruption could be ^C in the terminal, but this could be any
other condition or event, as this is up to the callback function
to implement.
People who are doing a commit expect a unified timestamp between
author and committer information when we're using the current timestamp.
Provide a single function that returns both author and committer
information so that they can have an identical timestamp when none is
specified in the environment.
In attempting to make a clever change that added fetch options as flags,
while keeping ABI and API compatibility, we screwed up. Bitfields in
structs are implementation-specific and are not necessarily ABI
compatible across compilers.
Make `update_fetchhead` a flags value which is weirdly named, but
that's a future problem. This removes the `report_unchanged` option from
API.
This is a leftover leaky abstraction. If consumers aren't meant to
_call_ the `free` function then they shouldn't _see_ the free function.
Move it out into a `git_config_backend_entry` that is, well, produced by
the config backends.
This makes our code messier but is an improvement for consumers.
Update our headers so that they can include the necessary definitions.
Docs generators (in particular, `clang -Xclang -ast-dump`) were unable
to see the necessary definitions.
Users can now override the "product" portion of the user-agent (via
GIT_OPT_SET_USER_AGENT_PRODUCT). This continues to default to "git/2.0",
but users may define their own string, or may opt out of sending a
user-agent entirely (by passing an empty string). Similarly, users may
now also opt-out of sending any additional "comment" information by
setting the GIT_OPT_SET_USER_AGENT value to an empty string.
Update `git_fetch_options` to break out the fetch options into
individual options. This prevents creating an API breaking change from
v1.7.0. `git_remote_update_tips` retains the `update_flags` to also
avoid an API breaking change.
Introduce `GIT_EREADONLY` and return it when a read-only configuration
is attempted to be mutated. This is preferred over the prior
`GIT_ENOTFOUND` which is not accurate.
Configuration read order and write order should be separated. For
example: configuration readers have a worktree level that is higher
priority than the local configuration _for reads_. Despite that, the
worktree configuration is not written to by default.
Use a new list, `writers`, to identify the write target.
To do this, we need another level of indirection between backend
instances (which are refcounted and shared amongst different git_config
instances) and the config reader/writer list (since each of those
different git_config instances can have different read/write
priorities).
We aren't upgrading options struct version numbers when we make ABI
changes. This is a future (v2.0+) plan for libgit2. In the meantime,
keep the version numbers at 1.
Introduce the logical concept of a worktree-level config. The new
value sits between _LOCAL and _APP to allow `git_config_get_*` to
'just work'.
The assumption of how `git_config_get_*` works was tested
experimentally by setting _WORKTREE to some nonsense value (like -3)
and watching the new test fail.
Since we use `git_push_options` as the options structure to our
`git_push` command, much like we do everywhere else, "push_options"
becomes ambiguous. "remote_options" isn't much better for us. Call them
"remote_push_options", which is still quite bad, and not particularly
insightful for end users, but at least something that we can discuss
unambiguously.
