summaryrefslogtreecommitdiff
path: root/remote.c
AgeCommit message (Collapse)AuthorFilesLines
2008-06-18clean up error conventions of remote.c:match_explicitLibravatar Jeff King1-21/+11
match_explicit is called for each push refspec to try to fully resolve the source and destination sides of the refspec. Currently, we look at each refspec and report errors on both the source and the dest side before aborting. It makes sense to report errors for each refspec, since an error in one is independent of an error in the other. However, reporting errors on the 'dst' side of a refspec if there has been an error on the 'src' side does not necessarily make sense, since the interpretation of the 'dst' side depends on the 'src' side (for example, when creating a new unqualified remote ref, we use the same type as the src ref). This patch lets match_explicit return early when the src side of the refspec is bogus. We still look at all of the refspecs before aborting the push, though. At the same time, we clean up the call signature, which previously took an extra "errs" flag. This was pointless, as we didn't act on that flag, but rather just passed it back to the caller. Instead, we now use the more traditional "return -1" to signal an error, and the caller aggregates the error count. This change fixes two bugs, as well: - the early return avoids a segfault when passing a NULL matched_src to guess_ref() - the check for multiple sources pointing to a single dest aborted if the "err" flag was set. Presumably the intent was not to bother with the check if we had no matched_src. However, since the err flag was passed in from the caller, we might abort the check just because a previous refspec had a problem, which doesn't make sense. In practice, this didn't matter, since due to the error flag we end up aborting the push anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25Merge branch 'js/config-cb'Libravatar Junio C Hamano1-2/+2
* js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
2008-05-25Merge branch 'db/clone-in-c'Libravatar Junio C Hamano1-0/+10
* db/clone-in-c: Add test for cloning with "--reference" repo being a subset of source repo Add a test for another combination of --reference Test that --reference actually suppresses fetching referenced objects clone: fall back to copying if hardlinking fails builtin-clone.c: Need to closedir() in copy_or_link_directory() builtin-clone: fix initial checkout Build in clone Provide API access to init_db() Add a function to set a non-default work tree Allow for having for_each_ref() list extra refs Have a constant extern refspec for "--tags" Add a library function to add an alternate to the alternates file Add a lockfile function to append to a file Mark the list of refs to fetch as const Conflicts: cache.h t/t5700-clone-reference.sh
2008-05-23Merge branch 'pb/push'Libravatar Junio C Hamano1-27/+54
* pb/push: add special "matching refs" refspec
2008-05-14Provide git_config with a callback-data parameterLibravatar Johannes Schindelin1-2/+2
git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11alloc_ref_from_str(): factor out a common pattern of alloc_ref from stringLibravatar Krzysztof Kowalczyk1-13/+10
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-1/+22
* db/learn-HEAD: Make ls-remote http://... list HEAD, like for git://... Make walker.fetch_ref() take a struct ref.
2008-05-05Merge branch 'pb/remote-mirror-config'Libravatar Junio C Hamano1-24/+29
* pb/remote-mirror-config: Add a remote.*.mirror configuration option
2008-05-04Have a constant extern refspec for "--tags"Libravatar Daniel Barkalow1-0/+9
The refspec refs/tags/*:refs/tags/* is sufficiently common and generic to merit having a constant instead of generating it as needed. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04add special "matching refs" refspecLibravatar Paolo Bonzini1-27/+54
This patch provides a way to specify "push matching heads" using a special refspec ":". This is useful because it allows "push = +:" as a way to specify that matching refs will be pushed but, in addition, forced updates will be allowed, which was not possible before. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-26Make ls-remote http://... list HEAD, like for git://...Libravatar Daniel Barkalow1-1/+22
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-24push: allow unqualified dest refspecs to DWIMLibravatar Jeff King1-3/+29
Previously, a push like: git push remote src:dst would go through the following steps: 1. check for an unambiguous 'dst' on the remote; if it exists, then push to that ref 2. otherwise, check if 'dst' begins with 'refs/'; if it does, create a new ref 3. otherwise, complain because we don't know where in the refs hierarchy to put 'dst' However, in some cases, we can guess about the ref type of 'dst' based on the ref type of 'src'. Specifically, before complaining we now check: 2.5. if 'src' resolves to a ref starting with refs/heads or refs/tags, then prepend that to 'dst' So now this creates a new branch on the remote, whereas it previously failed with an error message: git push master:newbranch Note that, by design, we limit this DWIM behavior only to source refs which resolve exactly (including symrefs which resolve to existing refs). We still complain on a partial destination refspec if the source is a raw sha1, or a ref expression such as 'master~10'. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-20Add a remote.*.mirror configuration optionLibravatar Paolo Bonzini1-24/+29
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-3/+18
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-04-12Fix config key miscount in url.*.insteadOfLibravatar Daniel Barkalow1-1/+1
Also tighten test to require it to be correct. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-26Merge branch 'jc/maint-fetch-regression-1.5.4'Libravatar Junio C Hamano1-6/+22
* jc/maint-fetch-regression-1.5.4: git-fetch test: test tracking fetch results, not just FETCH_HEAD Fix branches file configuration Tighten refspec processing Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.
2008-03-26Fix branches file configurationLibravatar Daniel Barkalow1-6/+22
Fetched remote branch from .git/branches/foo should fetch into refs/heads/foo. Also when partial URL is given, the fetched head should always be remote HEAD, and the result should not be stored anywhere. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-26Tighten refspec processingLibravatar Daniel Barkalow1-39/+137
This changes the pattern matching code to not store the required final / before the *, and then to require each side to be a valid ref (or empty). In particular, any refspec that looks like it should be a pattern but doesn't quite meet the requirements will be found to be invalid as a fallback non-pattern. This was cherry picked from commit ef00d15 (Tighten refspec processing, 2008-03-17), and two fix-up commits 46220ca (remote.c: Fix overtight refspec validation, 2008-03-20) and 7d19da4 (refspec: allow colon-less wildcard "refs/category/*", 2008-03-25) squashed in. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-25refspec: allow colon-less wildcard "refs/category/*"Libravatar Junio C Hamano1-7/+11
"git push --tags elsewhere" is implemented in terms of wildcarded refspec "refs/tags/*" these days, and the user wants to push the tags under the same name to the other branch. This resurrects the support for it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-22remote.c: Fix overtight refspec validationLibravatar Junio C Hamano1-46/+111
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-18Tighten refspec processingLibravatar Daniel Barkalow1-9/+38
This changes the pattern matching code to not store the required final / before the *, and then to require each side to be a valid ref (or empty). In particular, any refspec that looks like it should be a pattern but doesn't quite meet the requirements will be found to be invalid as a fallback non-pattern. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-01Make git-remote a builtinLibravatar Johannes Schindelin1-1/+2
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27Merge branch 'jm/free'Libravatar Junio C Hamano1-2/+1
* jm/free: Avoid unnecessary "if-before-free" tests. Conflicts: builtin-branch.c
2008-02-27Merge branch 'db/push-single-with-HEAD'Libravatar Junio C Hamano1-1/+9
* db/push-single-with-HEAD: Resolve value supplied for no-colon push refspecs
2008-02-24url rewriting: take longest and first matchLibravatar Junio C Hamano1-16/+38
Earlier we had a cop-out in the documentation to make the behaviour "undefined" if configuration had more than one insteadOf that would match the target URL, like this: [url "git://git.or.cz/"] insteadOf = "git.or.cz:" ; (1) insteadOf = "repo.or.cz:" ; (2) [url "/local/mirror/"] insteadOf = "git.or.cz:myrepo" ; (3) insteadOf = "repo.or.cz:" ; (4) It would be most natural to take the longest and first match, i.e. - rewrite "git.or.cz:frotz" to "git://git.or.cz/frotz" by using (1), - rewrite "git.or.cz:myrepo/xyzzy" to "/local/mirror/xyzzy" by favoring (3) over (1), and - rewrite "repo.or.cz:frotz" to "git://git.or.cz/frotz" by favoring (2) over (4). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-24Add support for url aliases in config filesLibravatar Daniel Barkalow1-3/+94
This allows users with different preferences for access methods to the same remote repositories to rewrite each other's URLs by pattern matching across a large set of similiarly set up repositories to each get the desired access. For example, if you don't have a kernel.org account, you might want settings like: [url "git://git.kernel.org/pub/"] insteadOf = master.kernel.org:/pub Then, if you give git a URL like: master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git it will act like you gave it: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git and you can cut-and-paste pull requests in email without fixing them by hand, for example. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-22Avoid unnecessary "if-before-free" tests.Libravatar Jim Meyering1-2/+1
This change removes all obvious useless if-before-free tests. E.g., it replaces code like this: if (some_expression) free (some_expression); with the now-equivalent: free (some_expression); It is equivalent not just because POSIX has required free(NULL) to work for a long time, but simply because it has worked for so long that no reasonable porting target fails the test. Here's some evidence from nearly 1.5 years ago: http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html FYI, the change below was prepared by running the following: git ls-files -z | xargs -0 \ perl -0x3b -pi -e \ 's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s' Note however, that it doesn't handle brace-enclosed blocks like "if (x) { free (x); }". But that's ok, since there were none like that in git sources. Beware: if you do use the above snippet, note that it can produce syntactically invalid C code. That happens when the affected "if"-statement has a matching "else". E.g., it would transform this if (x) free (x); else foo (); into this: free (x); else foo (); There were none of those here, either. If you're interested in automating detection of the useless tests, you might like the useless-if-before-free script in gnulib: [it *does* detect brace-enclosed free statements, and has a --name=S option to make it detect free-like functions with different names] http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free Addendum: Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20Resolve value supplied for no-colon push refspecsLibravatar Daniel Barkalow1-1/+9
When pushing a refspec like "HEAD", we used to treat it as "HEAD:HEAD", which didn't work without rewriting. Instead, we should resolve the ref. If it's a symref, further require it to point to a branch, to avoid doing anything especially unexpected. Also remove the rewriting previously added in builtin-push. Since the code for "HEAD" uses the regular refspec parsing, it automatically handles "+HEAD" without anything special. [jc: added a further test to make sure that "remote.*.push = HEAD" works] Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-19Use ALLOC_GROW in remote.{c,h}Libravatar Daniel Barkalow1-72/+46
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-15Validate nicknames of remote branches to prohibit confusing onesLibravatar Daniel Barkalow1-1/+11
The original problem was that the parsers for configuration files were getting confused by seeing as nicknames remotes that involved directory-changing characters. In particular, the branches config file for ".." was particularly mystifying on platforms that can open directories and read odd data from them. The validation function was written by Junio Hamano (with a typo corrected). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-11remote.c: guard config parser from value=NULLLibravatar Junio C Hamano1-3/+6
branch.*.{remote,merge} expect a string value Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>