mirror of
https://github.com/git/git.git
synced 2024-11-15 05:33:04 +01:00
9e3751d443
When we create each branch struct, we fill in the
"remote_name" field from the config, and then fill in the
actual "remote" field (with a "struct remote") based on that
name. However, it turns out that nobody really cares about
the latter field. The only two sites that access it at all
are:
1. git-merge, which uses it to notice when the branch does
not have a remote defined. But we can easily replace this
with looking at remote_name instead.
2. remote.c itself, when setting up the @{upstream} merge
config. But we don't need to save the "remote" in the
"struct branch" for that; we can just look it up for
the duration of the operation.
So there is no need to have both fields; they are redundant
with each other (the struct remote contains the name, or you
can look up the struct from the name). It would be nice to
simplify this, especially as we are going to add matching
pushremote config in a future patch (and it would be nice to
keep them consistent).
So which one do we keep and which one do we get rid of?
If we had a lot of callers accessing the struct, it would be
more efficient to keep it (since you have to do a lookup to
go from the name to the struct, but not vice versa). But we
don't have a lot of callers; we have exactly one, so
efficiency doesn't matter. We can decide this based on
simplicity and readability.
And the meaning of the struct value is somewhat unclear. Is
it always the remote matching remote_name? If remote_name is
NULL (i.e., no per-branch config), does the struct fall back
to the "origin" remote, or is it also NULL? These questions
will get even more tricky with pushremotes, whose fallback
behavior is more complicated. So let's just store the name,
which pretty clearly represents the branch.*.remote config.
Any lookup or fallback behavior can then be implemented in
helper functions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
123 lines
3.2 KiB
Text
123 lines
3.2 KiB
Text
Remotes configuration API
|
|
=========================
|
|
|
|
The API in remote.h gives access to the configuration related to
|
|
remotes. It handles all three configuration mechanisms historically
|
|
and currently used by Git, and presents the information in a uniform
|
|
fashion. Note that the code also handles plain URLs without any
|
|
configuration, giving them just the default information.
|
|
|
|
struct remote
|
|
-------------
|
|
|
|
`name`::
|
|
|
|
The user's nickname for the remote
|
|
|
|
`url`::
|
|
|
|
An array of all of the url_nr URLs configured for the remote
|
|
|
|
`pushurl`::
|
|
|
|
An array of all of the pushurl_nr push URLs configured for the remote
|
|
|
|
`push`::
|
|
|
|
An array of refspecs configured for pushing, with
|
|
push_refspec being the literal strings, and push_refspec_nr
|
|
being the quantity.
|
|
|
|
`fetch`::
|
|
|
|
An array of refspecs configured for fetching, with
|
|
fetch_refspec being the literal strings, and fetch_refspec_nr
|
|
being the quantity.
|
|
|
|
`fetch_tags`::
|
|
|
|
The setting for whether to fetch tags (as a separate rule from
|
|
the configured refspecs); -1 means never to fetch tags, 0
|
|
means to auto-follow tags based on the default heuristic, 1
|
|
means to always auto-follow tags, and 2 means to fetch all
|
|
tags.
|
|
|
|
`receivepack`, `uploadpack`::
|
|
|
|
The configured helper programs to run on the remote side, for
|
|
Git-native protocols.
|
|
|
|
`http_proxy`::
|
|
|
|
The proxy to use for curl (http, https, ftp, etc.) URLs.
|
|
|
|
struct remotes can be found by name with remote_get(), and iterated
|
|
through with for_each_remote(). remote_get(NULL) will return the
|
|
default remote, given the current branch and configuration.
|
|
|
|
struct refspec
|
|
--------------
|
|
|
|
A struct refspec holds the parsed interpretation of a refspec. If it
|
|
will force updates (starts with a '+'), force is true. If it is a
|
|
pattern (sides end with '*') pattern is true. src and dest are the
|
|
two sides (including '*' characters if present); if there is only one
|
|
side, it is src, and dst is NULL; if sides exist but are empty (i.e.,
|
|
the refspec either starts or ends with ':'), the corresponding side is
|
|
"".
|
|
|
|
An array of strings can be parsed into an array of struct refspecs
|
|
using parse_fetch_refspec() or parse_push_refspec().
|
|
|
|
remote_find_tracking(), given a remote and a struct refspec with
|
|
either src or dst filled out, will fill out the other such that the
|
|
result is in the "fetch" specification for the remote (note that this
|
|
evaluates patterns and returns a single result).
|
|
|
|
struct branch
|
|
-------------
|
|
|
|
Note that this may end up moving to branch.h
|
|
|
|
struct branch holds the configuration for a branch. It can be looked
|
|
up with branch_get(name) for "refs/heads/{name}", or with
|
|
branch_get(NULL) for HEAD.
|
|
|
|
It contains:
|
|
|
|
`name`::
|
|
|
|
The short name of the branch.
|
|
|
|
`refname`::
|
|
|
|
The full path for the branch ref.
|
|
|
|
`remote_name`::
|
|
|
|
The name of the remote listed in the configuration.
|
|
|
|
`merge_name`::
|
|
|
|
An array of the "merge" lines in the configuration.
|
|
|
|
`merge`::
|
|
|
|
An array of the struct refspecs used for the merge lines. That
|
|
is, merge[i]->dst is a local tracking ref which should be
|
|
merged into this branch by default.
|
|
|
|
`merge_nr`::
|
|
|
|
The number of merge configurations
|
|
|
|
branch_has_merge_config() returns true if the given branch has merge
|
|
configuration given.
|
|
|
|
Other stuff
|
|
-----------
|
|
|
|
There is other stuff in remote.h that is related, in general, to the
|
|
process of interacting with remotes.
|
|
|
|
(Daniel Barkalow)
|