| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make socket I/O non-blocking and add optional timeouts.
Users may now set `GIT_OPT_SET_SERVER_CONNECT_TIMEOUT` to set a shorter
connection timeout. (The connect timeout cannot be longer than the
operating system default.) Users may also now configure the socket read
and write timeouts with `GIT_OPT_SET_SERVER_TIMEOUT`.
By default, connects still timeout based on the operating system
defaults (typically 75 seconds) and socket read and writes block.
Add a test against our custom testing git server that ensures that we
can timeout reads against a slow server.
|
| |
|
|
|
|
|
|
| |
The `gitno` buffer interface is another layer on top of socket reads.
Abstract it a bit into a "static string" that has `git_str` like
semantics but without heap allocation which moves the actual reading
logic into the socket / stream code, and allows for easier future usage
of a static / stack-allocated `git_str`-like interface.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`git__timer` is now `git_time_monotonic`, and returns milliseconds
since an arbitrary epoch.
Using a floating point to store the number of seconds elapsed was
clever, as it better supports the wide range of precision from the
different monotonic clocks of different systems. But we're a version
control system, not a real-time clock.
Milliseconds is a good enough precision for our work _and_ it's the
units that system calls like `poll` take and that our users interact
with.
Make `git_time_monotonic` return the monotonically increasing number
of milliseconds "ticked" since some arbitrary epoch.
|
| |\
| |
| | |
Shallow (#6396) with some fixes from review
|
| | |
| |
| |
| |
| | |
The `depth` field is suitable to specify unshallowing; provide an enum
to aide in specifying the `unshallow` value.
|
| | |
| |
| |
| |
| |
| | |
Users should provide us an array of object ids; we don't need a separate
type. And especially, we should not be mutating user-providing values.
Instead, use `git_oid *` in the shallow code.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Teach the smart transport more about oid types, instead of assuming SHA1.
|
| | | |
|
| | |
| |
| |
| |
| | |
The opt mechanism isn't _really_ meant to be for feature flags, and it's
weird to feature flag shallow / unshallow at all.
|
| | |\ |
|
| | |\ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |\ \ \ |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | |\ \ \ \ |
|
| | | | | | | |
|
| | |\ \ \ \ \
| | | |/ / /
| | |/| | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | |\ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Currently, we expose the function `git_repository_shallow_roots` to get
all grafted roots of the repository. This already paints us into a
corner, though, as we certainly need to experiment with some
functionality of the grafting mechanism before we can happily expose
some of its functionality. Most importantly, we need to get right when
to refresh grafts and when not.
Thus, this commit removes the public function with no public
replacement. We should first try and see what usecases people come up
with to e.g. expose the `git_grafts` mechanism directly in the future
or do something different altogether. Instead, we provide an internal
interface to get weak pointers to the grafting structs part of the
repository itself.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The shallow roots are in fact another user of the grafting mechanism,
and in essence they do use the same file format for grafted commits.
Thus, instead of hand-coding the parsing logic a second time, we can
just reuse the `git_grafts` structure for shallow commits, as well.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Parsing of grafts files is currently contained in the repository code.
To make grafts-related logic more self-contained, move it into
"grafts.c" instead.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In order to increase maintainability in the future, we should try to
make structures as self-contained and opaque to its users as possible.
Thus it is probably not a good idea to just typedef `git_graftmap` to
`git_oidmap`, as that will make it a lot harder in the future to extend
the API in the future, if this need ever arises.
Refactor the code to instead declare a real structure `git_grafts`,
which is completely opaque to its callers.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | |_|_|_|_|/
|/| | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
sha256: less hardcoded SHA1 types and lengths
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
