summaryrefslogtreecommitdiff
path: root/remote.h
AgeCommit message (Collapse)AuthorFilesLines
2008-05-11alloc_ref_from_str(): factor out a common pattern of alloc_ref from stringLibravatar Krzysztof Kowalczyk1-0/+2
Also fix an underallocation in walker.c::interpret_target(). Signed-off-by: Krzysztof Kowalczyk <kkowalczyk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-08Merge branch 'db/learn-HEAD'Libravatar Junio C Hamano1-0/+2
* db/learn-HEAD: Make ls-remote http://... list HEAD, like for git://... Make walker.fetch_ref() take a struct ref.
2008-04-26Make ls-remote http://... list HEAD, like for git://...Libravatar Daniel Barkalow1-0/+2
This makes a struct ref able to represent a symref, and makes http.c able to recognize one, and makes transport.c look for "HEAD" as a ref in the list, and makes it dereference symrefs for the resulting ref, if any. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-20Add a remote.*.mirror configuration optionLibravatar Paolo Bonzini1-0/+1
This patch adds a remote.*.mirror configuration option that, when set, automatically puts git-push in --mirror mode for that remote. Furthermore, the option is set automatically by `git remote add --mirror'. The code in remote.c to parse remote.*.skipdefaultupdate had a subtle problem: a comment in the code indicated that special care was needed for boolean options, but this care was not used in parsing the option. Since I was touching related code, I did this fix too. [jc: and I further fixed up the "ignore boolean" code.] Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-18git-remote: reject adding remotes with invalid namesLibravatar Jonas Fonseca1-0/+1
This can happen if the arguments to git-remote add is switched by the user, and git would only show an error if fetching was also requested. Fix it by using the refspec parsing engine to check if the requested name can be parsed as a remote before add it. Also cleanup so that the "remote.<name>.url" config name buffer is only initialized once. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-22remote.c: Fix overtight refspec validationLibravatar Junio C Hamano1-1/+2
We tightened the refspec validation code in an earlier commit ef00d15 (Tighten refspec processing, 2008-03-17) per my suggestion, but the suggestion was misguided to begin with and it broke this usage: $ git push origin HEAD~12:master The syntax of push refspecs and fetch refspecs are similar in that they are both colon separated LHS and RHS (possibly prefixed with a + to force), but the similarity ends there. For example, LHS in a push refspec can be anything that evaluates to a valid object name at runtime (except when colon and RHS is missing, or it is a glob), while it must be a valid-looking refname in a fetch refspec. To validate them correctly, the caller needs to be able to say which kind of refspecs they are. It is unreasonable to keep a single interface that cannot tell which kind it is dealing with, and ask it to behave sensibly. This commit separates the parsing of the two into different functions, and clarifies the code to implement the parsing proper (i.e. splitting into two parts, making sure both sides are wildcard or neither side is). This happens to also allow pushing a commit named with the esoteric "look for that string" syntax: $ git push ../test.git ':/remote.c: Fix overtight refspec:master' Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-01Make git-remote a builtinLibravatar Johannes Schindelin1-0/+1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-19Use ALLOC_GROW in remote.{c,h}Libravatar Daniel Barkalow1-0/+4
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-03Add remote.<name>.proxyLibravatar Sam Vilain1-0/+5
As well as allowing a default http.proxy option, allow it to be set per-remote. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-09Teach send-pack a mirror modeLibravatar Andy Whitcroft1-0/+7
Existing "git push --all" is almost perfect for backing up to another repository, except that "--all" only means "all branches" in modern git, and it does not delete old branches and tags that exist at the back-up repository that you have removed from your local repository. This teaches "git-send-pack" a new "--mirror" option. The difference from the "--all" option are that (1) it sends all refs, not just branches, and (2) it deletes old refs you no longer have on the local side from the remote side. Original patch by Junio C Hamano. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02Miscellaneous const changes and utilitiesLibravatar Daniel Barkalow1-3/+7
The list of remote refs in struct transport should be const, because builtin-fetch will get confused if it changes. The url in git_connect should be const (and work on a copy) instead of requiring the caller to copy it. match_refs doesn't modify the refspecs it gets. get_fetch_map and get_remote_ref don't change the list they get. Allow transport get_refs_list methods to modify the struct transport. Add a function to copy a list of refs, when a function needs a mutable copy of a const list. Add a function to check the type of a ref, as per the code in connect.c Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-28git-fetch: do not fail when remote branch disappearsLibravatar Junio C Hamano1-1/+4
When the branch named with branch.$name.merge is not covered by the fetch configuration for the remote repository named with branch.$name.remote, we automatically add that branch to the set of branches to be fetched. However, if the remote repository does not have that branch (e.g. it used to exist, but got removed), this is not a reason to fail the git-fetch itself. The situation however will be noticed if git-fetch was called by git-pull, as the resulting FETCH_HEAD would not have any entry that is marked for merging. Acked-By: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-15Remove duplicate ref matches in fetchLibravatar Daniel Barkalow1-0/+5
If multiple refspecs matched the same ref, the update would be processed multiple times. Now having the same destination for the same source has no additional effect, and having the same destination for different sources is an error. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-19Rename remote.uri to remote.url within remote handling internalsLibravatar Shawn O. Pearce1-3/+3
Anyplace we talk about the address of a remote repository we always refer to it as a URL, especially in the configuration file and .git/remotes where we call it "remote.$n.url" or start the first line with "URL:". Calling this value a uri within the internal C code just doesn't jive well with our commonly accepted terms. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Correct handling of branch.$name.merge in builtin-fetchLibravatar Shawn O. Pearce1-2/+1
My prior bug fix for git-push titled "Don't configure remote "." to fetch everything to itself" actually broke t5520 as we were unable to evaluate a branch configuration of: [branch "copy"] remote = . merge = refs/heads/master as remote "." did not have a "remote...fetch" configuration entry to offer up refs/heads/master as a possible candidate available to be fetched and merged. In shell script git-fetch and prior to the above mentioned commit this was hardcoded for a url of "." to be the set of local branches. Chasing down this bug led me to the conclusion that our prior behavior with regards to branch.$name.merge was incorrect. In the shell script based git-fetch implementation we only fetched and merged a branch if it appeared both in branch.$name.merge *and* in remote.$r.fetch, where $r = branch.$name.remote. In other words in the following config file: [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = refs/heads/master:refs/remotes/origin/master [branch "master"] remote = origin merge = refs/heads/master [branch "pu"] remote = origin merge = refs/heads/pu Attempting to run `git pull` while on branch "pu" would always give the user "Already up-to-date" as git-fetch did not fetch pu and thus did not mark it for merge in .git/FETCH_HEAD. The configured merge would always be ignored and the user would be left scratching her confused head wondering why merge did not work on "pu" but worked fine on "master". If we are using the "default fetch" specification for the current branch and the current branch has a branch.$name.merge configured we now union it with the list of refs in remote.$r.fetch. This way the above configuration does what the user expects it to do, which is to fetch only "master" by default but when on "pu" to fetch both "master" and "pu". This uncovered some breakage in the test suite where old-style Cogito branches (.git/branches/$r) did not fetch the branches listed in .git/config for merging and thus did not actually merge them if the user tried to use `git pull` on that branch. Junio and I discussed it on list and felt that the union approach here makes more sense to DWIM for the end-user than silently ignoring their configured request so the test vectors for t5515 have been updated to include for-merge lines in .git/FETCH_HEAD where they have been configured for-merge in .git/config. Since we are now performing a union of the fetch specification and the merge specification and we cannot allow a branch to be listed twice (otherwise it comes out twice in .git/FETCH_HEAD) we need to perform a double loop here over all of the branch.$name.merge lines and try to set their merge flag if we have already schedule that branch for fetching by remote.$r.fetch. If no match is found then we must add new specifications to fetch the branch but not store it as no local tracking branch has been designated. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-19Add matching and parsing for fetch-side refspec rulesLibravatar Daniel Barkalow1-0/+24
Also exports parse_ref_spec(). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Report information on branches from remote.hLibravatar Daniel Barkalow1-0/+18
This adds full parsing for branch.<name> sections and functions to interpret the results usefully. It incidentally corrects the fetch configuration information for legacy branches/* files with '#' characters in the URLs. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Add uploadpack configuration info to remote.Libravatar Daniel Barkalow1-0/+1
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-11Add for_each_remote() function, and extend remote_find_tracking()Libravatar Johannes Schindelin1-1/+4
The function for_each_remote() does exactly what the name suggests. The function remote_find_tracking() was extended to be able to search remote refs for a given local ref. The caller sets either src or dst (but not both) in the refspec parameter, and remote_find_tracking() will fill in the other and return 0. Both changes are required for the next step: simplification of git-branch's --track functionality. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-09Add allocation and freeing functions for struct refsLibravatar Daniel Barkalow1-0/+7
Instead of open-coding allocation wherever it happens, have a function. Also, add a function to free a list of refs, which we currently never actually do. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-20Add handlers for fetch-side configuration of remotes.Libravatar Daniel Barkalow1-0/+11
These follow the pattern of the push side configuration, but aren't taken from anywhere else, because git-fetch is still in shell. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Move refspec parser from connect.c and cache.h to remote.{c,h}Libravatar Daniel Barkalow1-0/+12
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Move remote parsing into a library file out of builtin-push.Libravatar Daniel Barkalow1-0/+18
The new parser is different from the one in builtin-push in two ways: the default is to use the current branch's remote, if there is one, before "origin"; and config is used in preference to remotes. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>