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.
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.
Emulating `git commit` is clunky - identifying your commit's parents is
part of the problem. Provide a helper to give you the parents given the
current repository state.
Most callers only need to _get_ error messages. Only callers implemented
more complicated functions (like a custom ODB for example) need to set
them.
(Callback users should likely ferry their own error information in their
callback payload.)
Provide two memory-backed configuration backends -- one that takes a
string in config file format `[section] key=value` and one that takes a
list of strings in `section.key=value` format.
A git_config_entry now knows the type of the origin for the entry
("file", "memory", etc) and the path details (for files, the path on
disk). This is propagated through snapshots.
The opaque `payload` on an entry is unnecessary and distracting; config
entries should follow the patterns of other objects and use space
elsewhere in the structure with a "base" config entry struct embedded.
