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.
The packbuilder tests should be deterministic. This comment suggests
that they are:
```
/*
* By default, packfiles are created with only one thread.
* Therefore we can predict the object ordering and make sure
* we create exactly the same pack as git.git does when *not*
* reusing existing deltas (as libgit2).
*
* $ cd tests/resources/testrepo.git
* $ git rev-list --objects HEAD | \
* git pack-objects -q --no-reuse-delta --threads=1 pack
* $ sha1sum pack-7f5fa362c664d68ba7221259be1cbd187434b2f0.pack
* 5d410bdf97cf896f9007681b92868471d636954b
*
*/
```
but it is disappointingly incorrect. As is evidenced by the fact that --
at least on _my_ machine -- that command does not actually produce that
output any longer.
Variations in things like the which compression library is actually
used, and its defaults, mean that we cannot accurately predict or
enforce the bytes in the packfile from one system to another.
Adjust the tests so that they do not believe that they should enforce
the bytes in the packfile. This allows broader compatibility with
zlib-compatible compression libraries, or other compression levels.
Git looks explicitly for `---` followed by whitespace (`isspace()`) to
determine when a patch line begins in a commit message. Match that
behavior. This ensures that we don't treat (say) `----` as a patch line
incorrectly.
When a configuration transaction is freed with `git_transaction_free` -
without first committing it - we should not `git_config_free`. We never
increased the refcount, so we certainly shouldn't decrease it.
Also, add a test around aborting a transaction without committing it.
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.
Ensure that we test for the expected error code (GIT_ENOTFOUND) on not
found refs. In addition, we don't need to handle the error case with an
explicit free; it's okay to leak memory on test failures.
It would seem that `get_backend_for_use` is primarily used when
writing config data -- either to set keys or delete them (based on the
possible values of `backend_use`). When git-config(1) is used for
side-effects, it will modify only the local (repository-level)
configuration unless explicitly overridden.
From git-config(1):
--local
For writing options: write to the repository .git/config file.
This is the default behavior.
`get_backend_for_use` does not have the ability to specify a config
level and typically is expected (it seems) to 'do the right thing'.
Taking its cue from git-config(1), don't update worktree-specific
config unless it's the only option.
If that functionality is needed by consumers, I assume they would find
the appropriate backend with `git_config_open_level` and feed that
`git_config` object through to the `git_config_set_*` functions (as
demonstrated in the provided test).
Now that worktree-level configuration can be read from disk and
manipulated in memory, we should be able to say we support
'extensions.worktreeConfig'.
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.
Don't munge the "trivial" tests, those are specifically about the
"trivial" resolutions for git's tree merge. (For example, adding a file
in a new branch and making no changes in the HEAD branch is something
that can be handled _trivially_.)
For tests of rename functionality, put them in the trees::rename tests.
Support a revspec of '@' to mean 'HEAD', but ensure that it's at the
start of the revspec. Previously we were erroneously allowing 'foo@' to
mean 'HEAD' as well. Instead, 'foo@' should be rejected.
Recent versions of Git for Windows allow a sane UNC style path to be
used directly in `safe.directory` (without needing the `%(prefix)`
silliness). Match that behavior.
On Windows, you may open a repo with UNC path format -- for example
\\share\foo\bar, or as a git-style path, //share/foo/bar. In this world,
Git for Windows expects you to translate this to
$(prefix)//share/foo/bar.
We can test for that by using the fact that local drives are exposed as
hidden shares. For example, C:\Foo is //localhost/C$/Foo/.
Provide a helper method in the tests to set up the safe.directory
configuration for a normal and bare repository to avoid some copy/pasta.
(Some copypasta will remain, since there's customizations to the file
that are not trivially abstractable.)
The POSIX `realpath` function canonicalizes relative paths, symbolic links,
and case (on case-insensitive filesystems). For example, on macOS, if you
create some file `/private/tmp/FOO`, and you call `realpath("/tmp/foo")`,
you get _the real path_ returned of `/private/tmp/FOO`.
To emulate this behavior on win32, we call `GetFullPathName` to handle the
relative to absolute path conversion, then call `GetLongPathName` to handle
the case canonicalization.
Clar handles multiple levels of hierarchy in a test name _but_ it does so
assuming that there are not tests at a parent folder level. In other words,
if you have some tests at path/core.c and path/win32.c, then you cannot have
tests in path.c. If you have tests in path.c, then the things in path/*.c
will be ignored.
Move the tests in path.c into path/core.c.
