|
6fc6eeb6
|
2021-12-24T15:14:38
|
|
remote: introduce `git_remote_connect_options`
The existing mechanism for providing options to remote fetch/push calls,
and subsequently to transports, is unsatisfactory. It requires an
options structure to avoid breaking the API and callback signatures.
1. Introduce `git_remote_connect_options` to satisfy those needs.
2. Add a new remote connection API, `git_remote_connect_ext` that will
take this new options structure. Existing `git_remote_connect` calls
will proxy to that. `git_remote_fetch` and `git_remote_push` will
proxy their fetch/push options to that as well.
3. Define the interaction between `git_remote_connect` and fetch/push.
Connect _may_ be called before fetch/push, but _need not_ be. The
semantics of which options would be used for these operations was
not specified if you specify options for both connect _and_ fetch.
Now these are defined that the fetch or push options will be used
_if_ they were specified. Otherwise, the connect options will be
used if they were specified. Otherwise, the library's defaults will
be used.
4. Update the transports to understand `git_remote_connect_options`.
This is a breaking change to the systems API.
|
|
1c176883
|
2018-09-07T10:36:15
|
|
remote: store the connection data in a private struct
This makes it easier to pass connection-related options around (proxy &
custom headers for now).
This fixes a bug in git_push_finish, which didn't reuse the provided
proxy if the connection closed between the call to `git_remote_push` and
the finish step.
|
|
0c7f49dd
|
2017-06-30T13:39:01
|
|
Make sure to always include "common.h" first
Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.
This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.
This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.
|
|
4f2b6093
|
2015-09-08T13:53:41
|
|
Tell the git_transport about the custom_headers
|
|
6d8f3a51
|
2015-07-28T08:28:33
|
|
Better param docs
|
|
08afd227
|
2015-07-27T18:32:55
|
|
Fix remaining documentation warnings
|
|
8f0104ec
|
2015-04-21T22:10:36
|
|
Remove the callbacks struct from the remote
Having the setting be different from calling its actions was not a great
idea and made for the sake of the wrong convenience.
Instead of that, accept either fetch options, push options or the
callbacks when dealing with the remote. The fetch options are currently
only the callbacks, but more options will be moved from setters and
getters on the remote to the options.
This does mean passing the same struct along the different functions but
the typical use-case will only call git_remote_fetch() or
git_remote_push() and so won't notice much difference.
|
|
|
05259114
|
2015-04-21T20:16:48
|
|
push: remove own copy of callbacks
The push object knows which remote it's associated with, and therefore
does not need to keep its own copy of the callbacks stored in the
remote.
Remove the copy and simply access the callbacks struct within the
remote.
|
|
|
efc2fec5
|
2015-04-19T00:55:00
|
|
push: report the update plan to the caller
It can be useful for the caller to know which update commands will be
sent to the server before the packfile is pushed up. git does this via
the pre-push hook.
We don't have hooks, but as it adds introspection into what is
happening, we can add a callback which performs the same function.
|
|
|
412a3808
|
2015-01-15T15:31:23
|
|
push: remove reflog message override
We always use "update by push".
|
|
|
659cf202
|
2015-01-07T12:23:05
|
|
Remove the signature from ref-modifying functions
The signature for the reflog is not something which changes
dynamically. Almost all uses will be NULL, since we want for the
repository's default identity to be used, making it noise.
In order to allow for changing the identity, we instead provide
git_repository_set_ident() and git_repository_ident() which allow a user
to override the choice of signature.
|
|
|
fe794b2e
|
2014-12-16T08:57:05
|
|
remote: remove git_push from the public API
Instead we provide git_remote_upload() and git_remote_update_tips() in
order to have a parallel API for fetching and pushing.
|
|
|
aad638f3
|
2014-11-07T15:00:11
|
|
push: use the common refspec parser
There is one well-known and well-tested parser which we should use,
instead of implementing parsing a second time.
The common parser is also augmented to copy the LHS into the RHS if the
latter is empty.
The expressions test had to change a bit, as we now catch a bad RHS of a
refspec locally.
|
|
b176eded
|
2013-09-19T14:52:57
|
|
Initial Implementation of progress reports during push
This adds the basics of progress reporting during push. While progress
for all aspects of a push operation are not reported with this change,
it lays the foundation to add these later. Push progress reporting
can be improved in the future - and consumers of the API should
just get more accurate information at that point.
The main areas where this is lacking are:
1) packbuilding progress: does not report progress during deltafication,
as this involves coordinating progress from multiple threads.
2) network progress: reports progress as objects and bytes are going
to be written to the subtransport (instead of as client gets
confirmation that they have been received by the server) and leaves
out some of the bytes that are transfered as part of the push protocol.
Basically, this reports the pack bytes that are written to the
subtransport. It does not report the bytes sent on the wire that
are received by the server. This should be a good estimate of
progress (and an improvement over no progress).
|
|
20858f6e
|
2013-02-19T06:22:58
|
|
Implemented push on the local transport
|
|
b8b897bb
|
2013-02-11T08:28:53
|
|
Add git_push_options, to set packbuilder parallelism
|
|
|
359fc2d2
|
2013-01-08T17:07:25
|
|
update copyrights
|
|
|
613d5eb9
|
2012-11-28T11:42:37
|
|
Push! By schu, phkelley, and congyiwu, et al
|