summaryrefslogtreecommitdiff
path: root/remote.c
AgeCommit message (Collapse)AuthorFilesLines
2007-12-14remote: Fix bogus make_branch() call in configuration reader.Libravatar Junio C Hamano1-1/+1
The configuration reader to enumerate branches that have configuration data were not careful enough and failed to skip "branch.<variable>" entries (e.g. branch.autosetupmerge). This resulted in bogus attempt to allocate huge memory. Noticed by David Miller. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-04Merge branch 'sp/refspec-match'Libravatar Junio C Hamano1-25/+3
* sp/refspec-match: refactor fetch's ref matching to use refname_match() push: use same rules as git-rev-parse to resolve refspecs add refname_match() push: support pushing HEAD to real branch name
2007-12-03Add remote.<name>.proxyLibravatar Sam Vilain1-0/+2
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-18refactor fetch's ref matching to use refname_match()Libravatar Steffen Prohaska1-21/+2
The old rules used by fetch were coded as a series of ifs. The old rules are: 1) match full refname if it starts with "refs/" or matches "HEAD" 2) verify that full refname starts with "refs/" 3) match abbreviated name in "refs/" if it starts with "heads/", "tags/", or "remotes/". 4) match abbreviated name in "refs/heads/" This is replaced by the new rules a) match full refname b) match abbreviated name prefixed with "refs/" c) match abbreviated name prefixed with "refs/heads/" The details of the new rules are different from the old rules. We no longer verify that the full refname starts with "refs/". The new rule (a) matches any full string. The old rules (1) and (2) were stricter. Now, the caller is responsible for using sensible full refnames. This should be the case for the current code. The new rule (b) is less strict than old rule (3). The new rule accepts abbreviated names that start with a non-standard prefix below "refs/". Despite this modifications the new rules should handle all cases as expected. Two tests are added to verify that fetch does not resolve short tags or HEAD in remotes. We may even think about loosening the rules a bit more and unify them with the rev-parse rules. This would be done by replacing ref_ref_fetch_rules with ref_ref_parse_rules. Note, the two new test would break. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-18push: use same rules as git-rev-parse to resolve refspecsLibravatar Steffen Prohaska1-4/+1
This commit changes the rules for resolving refspecs to match the rules for resolving refs in rev-parse. git-rev-parse uses clear rules to resolve a short ref to its full name, which are well documented. The rules for resolving refspecs documented in git-send-pack were less strict and harder to understand. This commit replaces them by the rules of git-rev-parse. The unified rules are easier to understand and better resolve ambiguous cases. You can now push from a repository containing several branches ending on the same short name. Note, this may break existing setups. For example, "master" will no longer resolve to "origin/master" even when there is no other "master" elsewhere. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-18make "find_ref_by_name" a public functionLibravatar Jeff King1-8/+0
This was a static in remote.c, but is generally useful. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-09Teach send-pack a mirror modeLibravatar Andy Whitcroft1-5/+10
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-10/+22
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-9/+13
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-24Merge branch 'db/fetch-pack'Libravatar Junio C Hamano1-38/+321
* db/fetch-pack: (60 commits) Define compat version of mkdtemp for systems lacking it Avoid scary errors about tagged trees/blobs during git-fetch fetch: if not fetching from default remote, ignore default merge Support 'push --dry-run' for http transport Support 'push --dry-run' for rsync transport Fix 'push --all branch...' error handling Fix compilation when NO_CURL is defined Added a test for fetching remote tags when there is not tags. Fix a crash in ls-remote when refspec expands into nothing Remove duplicate ref matches in fetch Restore default verbosity for http fetches. fetch/push: readd rsync support Introduce remove_dir_recursively() bundle transport: fix an alloc_ref() call Allow abbreviations in the first refspec to be merged Prevent send-pack from segfaulting when a branch doesn't match Cleanup unnecessary break in remote.c Cleanup style nit of 'x == NULL' in remote.c Fix memory leaks when disconnecting transport instances Ensure builtin-fetch honors {fetch,transfer}.unpackLimit ...
2007-10-19send-pack: respect '+' on wildcard refspecsLibravatar Jeff King1-0/+2
When matching source and destination refs, we were failing to pull the 'force' parameter from wildcard refspecs (but not explicit ones) and attach it to the ref struct. This adds a test for explicit and wildcard refspecs; the latter fails without this patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15Fix a crash in ls-remote when refspec expands into nothingLibravatar Alex Riesen1-1/+2
Originally-by: Väinö Järvelä <v@pp.inet.fi> Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15Remove duplicate ref matches in fetchLibravatar Daniel Barkalow1-0/+27
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-24Prevent send-pack from segfaulting when a branch doesn't matchLibravatar Shawn O. Pearce1-1/+4
If `git push url foo` can't find a local branch named foo we can't match it to any remote branch as the local branch is NULL and its name is probably at position 0x34 in memory. On most systems that isn't a valid address for git-send-pack's virtual address space and we segfault. If we can't find a source match and we have no destination we need to abort the match function early before we try to match the destination against the remote. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-24Cleanup unnecessary break in remote.cLibravatar Shawn O. Pearce1-6/+3
This simple change makes the body of "case 0" easier to read; no matter what the value of matched_src is we want to break out of the switch and not fall through. We only want to display an error if matched_src is NULL, as this indicates there is no local branch matching the input. Also modified the default case's error message so it uses one less line of text. Even at 8 column per tab indentation we still don't break 80 columns with this new formatting. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-24Cleanup style nit of 'x == NULL' in remote.cLibravatar Shawn O. Pearce1-3/+3
Git style tends to prefer "!x" over "x == NULL". Make it so in these handful of locations that were not following along. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Rename remote.uri to remote.url within remote handling internalsLibravatar Shawn O. Pearce1-17/+17
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-8/+5
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-19builtin-fetch: Don't segfault on "fetch +foo"Libravatar Shawn O. Pearce1-2/+1
If we are fetching something and were configured to do a forced fetch and have no local ref to store the fetched object into we cannot mark the local ref as having a forced update. Instead we should just silently discard the + request. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-19Don't configure remote "." to fetch everything to itselfLibravatar Shawn O. Pearce1-4/+0
When we are talking about a remote URI of "." we are really talking about *this* repository that we are fetching into or pushing out of. There are no matching tracking branches for this repository; we do not attempt to map a ref back to ourselves as this would either create an infinite cycle (for example "fetch = +refs/*:refs/mine/*") or it causes problems when we attempt to push back to ourselves. So we really cannot setup a remote like this: [remote "."] url = . fetch = +refs/*:refs/* In the case of `git push . B:T` to fast-forward branch T to B's current commit git-send-pack will update branch T to B, assuming that T is the remote tracking branch for B. This update is performed immediately before git-send-pack asks git-receive-pack to perform the same update, and git-receive-pack then fails because T is not where git-send-pack told it to expect T to be at. In the case of `git fetch .` we really should do the same thing as `git fetch $otherrepo`, that is load .git/FETCH_HEAD with the commit of HEAD, so that `git pull .` will report "Already up-to-date". We have always behaved like this before on this insane request and we should at least continue to behave the same way. With the above (bad) remote configuration we were instead getting fetch errors about funny refs, e.g. "refs/stash". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Add matching and parsing for fetch-side refspec rulesLibravatar Daniel Barkalow1-1/+124
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-11/+146
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/+5
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-15/+45
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-09Some cosmetic changes to remote libraryLibravatar Daniel Barkalow1-10/+11
Functions for managing ref lists were named based on their use in match_refs (for push). For fetch, they will be used for other purposes, so rename them as a separate patch to make the future code readable. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-09Add allocation and freeing functions for struct refsLibravatar Daniel Barkalow1-3/+22
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-07-02"git-push $URL" without refspecs pushes only matching branchesLibravatar Junio C Hamano1-0/+7
When "git push" is run without any refspec (neither on the command line nor in the config), we used to push "matching refs" in the sense that anything under refs/ hierarchy that exist on both ends were updated. This used to be a sane default for publishing your repository to another back when we did not have refs/remotes/ hierarchy, but it does not make much sense these days. This changes the semantics to push only "matching branches". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-16Merge branch 'jc/remote'Libravatar Junio C Hamano1-82/+89
* jc/remote: git-push: Update description of refspecs and add examples remote.c: "git-push frotz" should update what matches at the source. remote.c: fix "git push" weak match disambiguation remote.c: minor clean-up of match_explicit() remote.c: refactor creation of new dst ref remote.c: refactor match_explicit_refs()
2007-06-16Fix pushing to a pattern with no dstLibravatar Daniel Barkalow1-2/+3
Refspecs with no colons are left with no dst value, because they are interepreted differently for fetch and push. For push, they mean to reuse the src side. Fix this for patterns. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-12Don't dereference a strdup-returned NULLLibravatar Jim Meyering1-1/+1
There are only a dozen or so uses of strdup in all of git. Of those, most seem ok, but this one isn't: Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09remote.c: "git-push frotz" should update what matches at the source.Libravatar Junio C Hamano1-6/+1
Earlier, when the local repository has a branch "frotz" and the remote repository has a tag "frotz" (but not branch "frotz"), "git-push frotz" mistakenly updated the tag at the remote side. This was because the partial refname matching code was applied independently on both source and destination side. With this fix, when a colon-less refspec is given to git-push, we first match it with the refs in the source repository, and update the matching ref in the destination repository. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09remote.c: fix "git push" weak match disambiguationLibravatar Junio C Hamano1-1/+0
When "git push A:B" is given, and A (or B) is not a full refname that begins with refs/, we require an unambiguous match with an existing ref. For this purpose, a match with a local branch or a tag (i.e. refs/heads/A and refs/tags/A) is called a "strong match", and any other match is called a "weak match". A partial refname is unambiguous when there is only one strong match with any number of weak matches, or when there is only one weak match and no other match. However, as reported by Sparse with Ramsay Jones recently, count_refspec_match() function had a bug where a variable in an inner block masked a different variable of the same name, which caused the weak matches to be ignored. This fixes it, and adds tests for the fix. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09remote.c: minor clean-up of match_explicit()Libravatar Junio C Hamano1-11/+12
When checking what ref the source refspec matches, we have no business setting the default for the destination, so move that code lower. Also simplify the result from the code block that matches the source side by making it set matched_src only upon unambiguous match. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09remote.c: refactor creation of new dst refLibravatar Junio C Hamano1-18/+17
This refactors open-coded sequence to create a new "struct ref" and link it to the tail of dst list into a new function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09remote.c: refactor match_explicit_refs()Libravatar Junio C Hamano1-73/+86
This does not change functionality; just splits one block that is deeply nested and indented out of a huge loop into a separate function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-08Fix push with refspecs containing wildcardsLibravatar Alex Riesen1-12/+27
Otherwise git push 'remote-name' 'refs/heads/*:refs/remotes/other/*' will consider references in "refs/heads" of the remote repository "remote-name", instead of the ones in "refs/remotes/other", which the given refspec clearly means. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-26Move refspec pattern matching to match_refs().Libravatar Daniel Barkalow1-3/+28
This means that send-pack and http-push will support pattern refspecs, so builtin-push.c doesn't have to expand them, and also git push can just turn --tags into "refs/tags/*", further simplifying builtin-push.c check_ref_format() gets a third "conditionally okay" result for something that's valid as a pattern but not as a particular ref. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Add handlers for fetch-side configuration of remotes.Libravatar Daniel Barkalow1-0/+59
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/+246
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/+223
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>