Allow `git_str_puts_escaped` to take an escaping prefix and an escaping
suffix; this allows for more options, including the ability to better
support escaping executed paths.
When using `git_process_new` on win32, resolve the path to the
application in the same way that we do on POSIX.
Search `PATH` for command to execute (unless the given executable is
fully qualified). In addition, better match Windows executable lookup
behavior itself (allowing the command to be `foo`, and looking for a
matching `foo.exe` or `foo.cmd`.)
Ensure that our `find_executable` behaves as expected:
* When the executable contains a fully- or partially-qualified filename
component (eg, `foo/bar`) that `PATH` is not searched; these paths are
relative to the current working directory.
* An empty segment in `PATH` (on POSIX systems) is treated as the
current directory; this is for compatibility with Bourne shells.
* When a file exists in `PATH`, it is actually executable (on POSIX)
It's certainly possible for the root filesystem to be case-sensitive
while /tmp is not, or vice versa. One example where this might happen
is when running Docker containers (like ci/docker/fedora) on macOS with
the repository checkout on AppleFS (not case sensitive) while the
container's /tmp is case sensitive.
This fix allows the test to pass under those circumstances as well.
GIT_REFERENCE_FORMAT_REFSPEC_SHORTHAND is documented to "interpret the
name as part of a refspec in shorthand form so the ONELEVEL naming rules
aren't enforced and 'master' becomes a valid name."
However, the multi-segment pseudoref check was not respecting this flag,
rejecting valid refspecs like "A/b" and "HEAD/feature" even when
SHORTHAND was set.
The single-segment check at line 1015 already honors this flag. This
change makes the multi-segment check at line 1021 consistent with that
behavior and with the documented intent.
Git itself accepts these refspec patterns without issue.
Prior to this patch the code correctly barfed on
control characters with values lower than \040 (space),
but failed to account for DEL.
This patch fixes the behavior to be consistent with git [1]:
> They cannot have ASCII control characters (i.e. bytes whose values are
> lower than \040, or \177 DEL)
[1]: https://git-scm.com/docs/git-check-ref-format#_description
In our tests for "onbranch" config conditionals we set HEAD to point to
various different branches via `git_repository_create_head()`. This
function circumvents the refdb though and directly writes to the "HEAD"
file. While this works now, it will create problems once we have
multiple refdb backends.
Furthermore, the function is about to go away in the next commit. So
let's prepare for that and use `git_reference_symbolic_create()`
instead.
To support multiple different reference backend implementations,
Git introduced a "refStorage" extension that stores the reference
storage format a Git client should try to use.
Wire up the logic to read this new extension when we open a repository
from disk. For now, only the "files" backend is supported by us. When
trying to open a repository that has a refstorage format that we don't
understand we now error out.
There are two functions that create a new repository that doesn't really
have references. While those are mostly non-functional when it comes to
references, we do expect that you can access the refdb, even if it's not
yielding any refs. For now we mark those to use the "files" backend, so
that the status quo is retained. Eventually though it might not be the
worst idea to introduce an explicit "in-memory" reference database. But
that is outside the scope of this patch series.
Some benchmarks require administrative privileges, namely the ones that
blow up the disk cache. Don't run them by default, to avoid obnoxious
sudo password prompts, etc. Users can specify `--admin` to run them.
The default in the world is to have a disk cache; it's exceptional to
_not_. Flip our naming, so that the (exceptional) `nocache` tests are
called out explicitly.
Introduce `--profile` support to the benchmark helper script, which will
invoke `perf` on Linux. Additionally, add a `--flamegraph` output
option based on that.
It can be useful to report the commit ID during benchmarks to track down
regressions; leverage the addition of that in `git version` during
benchmark runs.
There's no such thing as a "loose object type" or a "packed object
type". There are only object types. Introduce `type_is_valid` and
deprecate `typeisloose`.
Introduce `git_oid_from_string`, `git_oid_from_prefix`, and
`git_oid_from_raw`, all of which take a `git_oid_t` that indicates what
type of OID should be parsed (SHA1 or SHA256).
This allows users to continue to use `git_oid_fromstr` without any code
changes, while remaining in a SHA1 world.
Note that these are not perfect analogs to the `fromstr` APIs.
* `git_oid_from_string` now takes a NUL terminated string, instead of
allowing for non-NUL terminated strings. Adding a NUL check feels like
an important safety consideration for C strings.
* `git_oid_from_prefix` should be used for an OID substring and length.
Previous usages of `git_oid_fromstr` with non-NUL terminated strings
should move to `git_oid_from_prefix` with the hexsize for the given OID
type.
There are several places where users may want to specify the type of
object IDs (sha1 or sha256) that should be used, for example, when
dealing with repositories, indexes, etc.
However, given that sha256 support remains disappointingly uncommon in
the wild, we should avoid hard API breaks when possible. Instead, update
these APIs to have an "extended" format (eg, `git_odb_open_ext`) that
provides an options structure with oid type information.
This allows callers who do care about sha256 to use it, and callers who
do not to avoid gratuitous API breakage.
There were a few oddities around HTTPS provider selection: namely,
`GIT_OPENSSL_DYNAMIC` implied `GIT_OPENSSL`, which made a bit of sense,
until we added FIPS support. In addition, dynamic OpenSSL for _hashes_
and dynamic OpenSSL for HTTPS was conflated in a few places.
Untangle these, and make `GIT_HTTPS_*` the define, for consistency with
other feature provider selection.
For consistency, specify the nanosecond option in the same way as other
options, and identify it as such. Split the detection of platform
support (`FindStatNsec`) and its selection (`SelectNsec`).
