| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
git_fetch_options was missing from the API docs because it lacked a
documentation comment above the struct declaration.
I used the git_checkout_options docstring as a template.
Also fixes a typo in git_remote_prune_refs (remote, not reamote).
|
| |
|
|
|
| |
Fallback describes the mechanism, while unspecified explains what the
user is thinking.
|
| |
|
|
|
|
|
|
| |
A remote's URLs are now modified according to the url.*.insteadOf
and url.*.pushInsteadOf configurations. This allows a user to
replace URL prefixes by setting the corresponding keys. E.g.
"url.foo.insteadOf = bar" would replace the prefix "bar" with the
new prefix "foo".
|
| |\
| |
| | |
Tackle remote API issues from bindings
|
| | |
| |
| |
| |
| |
| |
| | |
When we moved from acting on the instance to acting on the
configuration, we dropped the validation of the passed refspec, which
can lead to writing an invalid refspec to the configuration. Bring that
validation back.
|
| | |
| |
| |
| |
| |
| | |
An anonymous remote is not configured and cannot therefore have
configured refspecs. Remove the parameter which adds this from the
constructor.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
These were left over from the culling as it's not clear which use-cases
might benefit from this. It is not clear that we want to support any
use-case which depends on changing the remote's idea of the base
refspecs rather than passing in different per-operation refspec list, so
remove these functions.
|
| |/ |
|
| |
|
|
|
| |
It has now become a no-op, so remove the function and all references to
it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The base refspecs changing can be a cause of confusion as to what is the
current base refspec set and complicate saving the remote's
configuration.
Change `git_remote_add_{fetch,push}()` to update the configuration
instead of an instance.
This finally makes `git_remote_save()` a no-op, it will be removed in a
later commit.
|
| |
|
|
|
| |
This is another option which we should not be keeping in the remote, but
is specific to each particular operation.
|
| |
|
|
|
|
| |
While this will rarely be different from the default, having it in the
remote adds yet another setting it has to keep around and can affect its
behaviour. Move it to the options.
|
| |
|
|
|
|
|
| |
Instead of having it set in a different place from every other callback,
put it the main structure. This removes some state from the remote and
makes it behave more like clone, where the constructors are passed via
the options.
|
| |
|
|
|
| |
Add a prune setting in the fetch options to allow to fall back to the
configuration (the default) or to set it on or off.
|
| |
|
|
|
|
| |
As a first step in removing the repository-saving logic, don't allow
chaning the url or push url from a remote object, but change the
configuration on the configuration immediately.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
We always use "update by push".
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| | |
Remote-tracking branch prunning
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This option does not get persisted to disk, which makes it different
from the rest of the setters. Remove it until we go all the way.
We still respect the configuration option, and it's still possible to
perform a one-time prune by calling the function.
|
| | | |
|
| |/
|
|
|
| |
Instead we provide git_remote_upload() and git_remote_update_tips() in
order to have a parallel API for fetching and pushing.
|
| |
|
|
|
|
|
|
|
|
| |
This makes them show up in the reference, even if the text itself isn't
the most descriptive.
These have been found with
grep -Przon '\n\ntypedef struct.*?\{' -- include
grep -Przon '\n\ntypedef enum.*?\{' -- include
|
| | |
|
| |
|
|
|
| |
On disconnect we simply ask the transport to close the connection, we do
not free it.
|
| |
|
|
|
| |
Make it clear that this is not the ls-remote command but a way to access
the data we have and how long it's kept around.
|
| |
|
|
|
| |
If the user does not pass any refspecs to push, try to use those
configured via the configuration or via add_push().
|
| |
|
|
|
|
|
|
|
| |
This function, similar in style to git_remote_fetch(), performs all the
steps required for a push, with a similar interface.
The remote callbacks struct has learnt about the push callbacks, letting
us set the callbacks a single time instead of setting some in the remote
and some in the push operation.
|
| |
|
|
| |
This brings it in line with the rest of the lookup functions.
|
| |\
| |
| | |
remote: accept a repo and name for renaming
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remote objects are not meant to be changed from under the user. We did
this in rename, but only the name and left the refspecs, such that a
save would save the wrong refspecs (and a fetch and anything else would
use the wrong refspecs).
Instead, let's simply take a name and not change any loaded remote from
under the user.
|
| |/
|
|
|
|
|
| |
This function does not in fact tell us anything, as almost anything with
a colon in it is a valid rsync-style SSH path; it can not tell us that
we do not support ftp or afp or similar as those are still valid SSH
paths and we do support that.
|
| |\
| |
| | |
remote: accept a repository and remote name for deletion
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We don't need the remote loaded, and the function extracted both of
these from the git_remote in order to do its work, so let's remote a
step and not ask for the loaded remote at all.
This fixes #2390.
|
| | | |
|
| |/
|
|
|
|
|
| |
With opportunistic ref updates, git has introduced the concept of having
base refspecs *and* refspecs that are active for a particular fetch.
Let's start by letting the user override the refspecs for download.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
It does the same as git_remote_supported_url() but has a name which
implies we'd check the URL for correctness while we're simply looking at
the scheme and looking it up in our lists.
While here, fix up the tests so we check all the combination of what's
supported.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This option make it easy to ignore anything about the server we're
connecting to, which is bad security practice. This was necessary as we
didn't use to expose detailed information about the certificate, but now
that we do, we should get rid of this.
If the user wants to ignore everything, they can still provide a
callback which ignores all the information passed.
|
| |/
|
|
|
|
|
|
|
| |
If the certificate validation fails (or always in the case of ssh),
let the user decide whether to allow the connection.
The data structure passed to the user is the native certificate
information from the underlying implementation, namely OpenSSL or
WinHTTP.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Move the transport registration mechanisms into a new header under
'sys/' because this is advanced stuff.
* Remove the 'priority' argument from the registration as it adds
unnecessary complexity. (Since transports cannot decline to operate,
only the highest priority transport is ever executed.) Users who
require per-priority transports can implement that in their custom
transport themselves.
* Simplify registration further by taking a scheme (eg "http") instead
of a prefix (eg "http://").
|
| |
|
|
|
| |
git_remote_set_transport now takes a transport factory rather than a transport
git_clone_options now allows the caller to specify a remote creation callback
|
| | |
|
| |
|
|
| |
This was a bad idea. Don't free except in the free function.
|
