summaryrefslogtreecommitdiff
path: root/builtin/remote.c
AgeCommit message (Collapse)AuthorFilesLines
2011-12-13Rename resolve_ref() to resolve_ref_unsafe()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
resolve_ref() may return a pointer to a shared buffer and can be overwritten by the next resolve_ref() calls. Callers need to pay attention, not to keep the pointer when the next call happens. Rename with "_unsafe" suffix to warn developers (or reviewers) before introducing new call sites. This patch is generated using the following command git grep -l 'resolve_ref(' -- '*.[ch]'|xargs sed -i 's/resolve_ref(/resolve_ref_unsafe(/g' Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-13Convert many resolve_ref() calls to read_ref*() and ref_exists()Libravatar Nguyễn Thái Ngọc Duy1-5/+3
resolve_ref() may return a pointer to a static buffer, which is not safe for long-term use because if another resolve_ref() call happens, the buffer may be changed. Many call sites though do not care about this buffer. They simply check if the return value is NULL or not. Convert all these call sites to new wrappers to reduce resolve_ref() calls from 57 to 34. If we change resolve_ref() prototype later on to avoid passing static buffer out, this helps reduce changes. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-08Merge branch 'jc/remote-setbranches-usage-fix'Libravatar Junio C Hamano1-1/+1
* jc/remote-setbranches-usage-fix: remote: fix set-branches usage
2011-11-08Merge branch 'fc/remote-seturl-usage-fix'Libravatar Junio C Hamano1-1/+1
* fc/remote-seturl-usage-fix: remote: fix remote set-url usage
2011-11-06remote: fix set-branches usageLibravatar Junio C Hamano1-1/+1
Bad copy-paste. Otherwise "git remote set-branches" without necessary argument will result in an error message and help for set-url subcommand. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-26Merge branch 'cn/fetch-prune'Libravatar Junio C Hamano1-1/+2
* cn/fetch-prune: fetch: treat --tags like refs/tags/*:refs/tags/* when pruning fetch: honor the user-provided refspecs when pruning refs remote: separate out the remote_find_tracking logic into query_refspecs t5510: add tests for fetch --prune fetch: free all the additional refspecs Conflicts: remote.c
2011-10-21Merge branch 'jc/match-refs-clarify'Libravatar Junio C Hamano1-2/+2
* jc/match-refs-clarify: rename "match_refs()" to "match_push_refs()" send-pack: typofix error message
2011-10-15fetch: honor the user-provided refspecs when pruning refsLibravatar Carlos Martín Nieto1-1/+2
If the user gave us refspecs on the command line, we should use those when deciding whether to prune a ref instead of relying on the refspecs in the config. Previously, running git fetch --prune origin refs/heads/master:refs/remotes/origin/master would delete every other ref under the origin namespace because we were using the refspec to filter the available refs but using the configured refspec to figure out if a ref had been deleted on the remote. This is clearly the wrong thing to do. Change prune_refs and get_stale_heads to simply accept a list of references and a list of refspecs. The caller of either function needs to decide what refspecs should be used to decide whether a ref is stale. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10Merge branch 'mz/remote-rename'Libravatar Junio C Hamano1-7/+21
* mz/remote-rename: remote: only update remote-tracking branch if updating refspec remote rename: warn when refspec was not updated remote: "rename o foo" should not rename ref "origin/bar" remote: write correct fetch spec when renaming remote 'remote'
2011-09-12rename "match_refs()" to "match_push_refs()"Libravatar Junio C Hamano1-2/+2
Yes, there is a warning that says the function is only used by push in big red letters in front of this function, but it didn't say a more important thing it should have said: what the function is for and what it does. Rename it and document it to avoid future confusion. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11remote: only update remote-tracking branch if updating refspecLibravatar Martin von Zweigbergk1-3/+7
'git remote rename' will only update the remote's fetch refspec if it looks like a default one. If the remote has no default fetch refspec, as in [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = +refs/heads/*:refs/remotes/upstream/* we would not update the fetch refspec and even if there is a ref called "refs/remotes/origin/master", we should not rename it, since it was not created by fetching from the remote. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11remote rename: warn when refspec was not updatedLibravatar Martin von Zweigbergk1-0/+6
When renaming a remote, we also try to update the fetch refspec accordingly, but only if it has the default format. For others, such as refs/heads/master:refs/heads/origin, we are conservative and leave it untouched. Let's give the user a warning about refspecs that are not updated, so he can manually update the config if necessary. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11remote: "rename o foo" should not rename ref "origin/bar"Libravatar Martin von Zweigbergk1-1/+1
When renaming a remote called 'o' using 'git remote rename o foo', git should also rename any remote-tracking branches for the remote. This does happen, but any remote-tracking branches starting with 'refs/remotes/o', such as 'refs/remotes/origin/bar', will also be renamed (to 'refs/remotes/foorigin/bar' in this case). Fix it by simply matching one more character, up to the slash following the remote name. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11remote: write correct fetch spec when renaming remote 'remote'Libravatar Martin von Zweigbergk1-4/+8
When renaming a remote whose name is contained in a configured fetch refspec for that remote, we currently replace the first occurrence of the remote name in the refspec. This is correct in most cases, but breaks if the remote name occurs in the fetch refspec before the expected place. For example, we currently change [remote "remote"] url = git://git.kernel.org/pub/scm/git/git.git fetch = +refs/heads/*:refs/remotes/remote/* into [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = +refs/heads/*:refs/origins/remote/* Reduce the risk of changing incorrect sections of the refspec by matching the entire ":refs/remotes/<name>/" instead of just "<name>". Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-25Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: whitespace: have SP on both sides of an assignment "=" update-ref: whitespace fix
2011-08-25whitespace: have SP on both sides of an assignment "="Libravatar Junio C Hamano1-1/+1
I've deliberately excluded the borrowed code in compat/nedmalloc directory. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19Merge branch 'jk/clone-cmdline-config'Libravatar Junio C Hamano1-12/+2
* jk/clone-cmdline-config: clone: accept config options on the command line config: make git_config_parse_parameter a public function remote: use new OPT_STRING_LIST parse-options: add OPT_STRING_LIST helper
2011-06-22remote: use new OPT_STRING_LISTLibravatar Jeff King1-12/+2
This saves us having our own callback function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-31Merge branch 'jk/maint-remote-mirror-safer'Libravatar Junio C Hamano1-2/+2
* jk/maint-remote-mirror-safer: remote: allow "-t" with fetch mirrors
2011-05-26remote: allow "-t" with fetch mirrorsLibravatar Jeff King1-2/+2
Commit 13fc2c1 (remote: disallow some nonsensical option combinations, 2011-03-30) made it impossible to use "remote add -t foo --mirror". The argument was that specifying specific branches is useless because: 1. Push mirrors do not want a refspec at all. 2. The point of fetch mirroring is to use a broad refspec like "refs/*", but using "-t" overrides that. Point (1) is valid; "-t" with push mirrors is useless. But point (2) ignored another side effect of using --mirror: it fetches the refs directly into the refs/ namespace as they are found upstream, instead of placing them in a separate-remote layout. So 13fc2c1 was overly constrictive, and disallowed reasonable specific-branch mirroring, like: git remote add -t heads/foo -t heads/bar --mirror=fetch which makes the local "foo" and "bar" branches direct mirrors of the remote, but does not fetch anything else. This patch restores the original behavior, but only for fetch mirrors. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06Merge branch 'jk/maint-remote-mirror-safer'Libravatar Junio C Hamano1-13/+49
* jk/maint-remote-mirror-safer: remote: deprecate --mirror remote: separate the concept of push and fetch mirrors remote: disallow some nonsensical option combinations
2011-03-30remote: deprecate --mirrorLibravatar Jeff King1-1/+7
The configuration created by plain --mirror is dangerous and useless, and we now have --mirror=fetch and --mirror=push to replace it. Let's warn the user. One alternative to this is to try to guess which type the user wants. In a non-bare repository, a fetch mirror doesn't make much sense, since it would overwrite local commits. But in a bare repository, you might use either type, or even both (e.g., if you are acting as an intermediate drop-point across two disconnected networks). So rather than try for complex heuristics, let's keep it simple. The user knows what they're trying to do, so let them tell us. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30remote: separate the concept of push and fetch mirrorsLibravatar Jeff King1-13/+38
git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30remote: disallow some nonsensical option combinationsLibravatar Jeff King1-0/+5
It doesn't make sense to use "-m" on a mirror, since "-m" sets up the HEAD symref in the remotes namespace, but with mirror, we are by definition not using a remotes namespace. Similarly, it does not make much sense to specify refspecs with --mirror. For a mirror you plan to push to, those refspecs will be ignored. For a mirror you are fetching from, there is no point in mirroring, since the refspec specifies everything you want to grab. There is one case where "--mirror -t <X>" would be useful. Because <X> is used as-is in the refspec, and because we append it to to refs/, you could mirror a subset of the hierarchy by doing: git remote add --mirror -t 'tags/*' But using anything besides a single branch as an argument to "-t" is not documented and only happens to work, so closing it off is not a serious regression. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-22Fix sparse warningsLibravatar Stephen Boyd1-1/+1
Fix warnings from 'make check'. - These files don't include 'builtin.h' causing sparse to complain that cmd_* isn't declared: builtin/clone.c:364, builtin/fetch-pack.c:797, builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78, builtin/merge-index.c:69, builtin/merge-recursive.c:22 builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426 builtin/notes.c:822, builtin/pack-redundant.c:596, builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149, builtin/remote.c:1512, builtin/remote-ext.c:240, builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384, builtin/unpack-file.c:25, builtin/var.c:75 - These files have symbols which should be marked static since they're only file scope: submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13, submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79, unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123, url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48 - These files redeclare symbols to be different types: builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571, usage.c:49, usage.c:58, usage.c:63, usage.c:72 - These files use a literal integer 0 when they really should use a NULL pointer: daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362 While we're in the area, clean up some unused #includes in builtin files (mostly exec_cmd.h). Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24Merge branch 'rs/opt-help-text'Libravatar Junio C Hamano1-2/+2
* rs/opt-help-text: verify-tag: document --verbose branch: improve --verbose description archive: improve --verbose description Describe various forms of "be quiet" using OPT__QUIET add OPT__FORCE add description parameter to OPT__QUIET add description parameter to OPT__DRY_RUN add description parameter to OPT__VERBOSE
2010-11-15add description parameter to OPT__DRY_RUNLibravatar René Scharfe1-1/+1
Allows better help text to be defined than "dry run". Also make use of the macro in places that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-15add description parameter to OPT__VERBOSELibravatar René Scharfe1-1/+1
Allows better help text to be defined than "be verbose". Also make use of the macro in places that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Change incorrect "remote branch" to "remote tracking branch" in C codeLibravatar Matthieu Moy1-3/+3
(Just like we did for documentation already) In the process, we change "non-remote branch" to "branch outside the refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch". The new formulation actually corresponds to how the code detects this case (i.e. prefixcmp(refname, "refs/remotes")). Also, we use 'remote-tracking branch' in generated merge messages (by merge an fmt-merge-msg). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-08Use parentheses and `...' where appropriateLibravatar Štěpán Němec1-1/+1
Remove some stray usage of other bracket types and asterisks for the same purpose. Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-08Use angles for placeholders consistentlyLibravatar Štěpán Němec1-1/+1
Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05string_list: Add STRING_LIST_INIT macro and make use of it.Libravatar Thiago Farina1-6/+6
Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'jp/string-list-api-cleanup'Libravatar Junio C Hamano1-34/+34
* jp/string-list-api-cleanup: string_list: Fix argument order for string_list_append string_list: Fix argument order for string_list_lookup string_list: Fix argument order for string_list_insert_at_index string_list: Fix argument order for string_list_insert string_list: Fix argument order for for_each_string_list string_list: Fix argument order for print_string_list
2010-06-27string_list: Fix argument order for string_list_appendLibravatar Julian Phillips1-23/+23
Update the definition and callers of string_list_append to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_insertLibravatar Julian Phillips1-3/+3
Update the definition and callers of string_list_insert to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for for_each_string_listLibravatar Julian Phillips1-8/+8
Update the definition and callers of for_each_string_list to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-21Merge branch 'gv/portable'Libravatar Junio C Hamano1-4/+7
* gv/portable: test-lib: use DIFF definition from GIT-BUILD-OPTIONS build: propagate $DIFF to scripts Makefile: Tru64 portability fix Makefile: HP-UX 10.20 portability fixes Makefile: HPUX11 portability fixes Makefile: SunOS 5.6 portability fix inline declaration does not work on AIX Allow disabling "inline" Some platforms lack socklen_t type Make NO_{INET_NTOP,INET_PTON} configured independently Makefile: some platforms do not have hstrerror anywhere git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition test_cmp: do not use "diff -u" on platforms that lack one fixup: do not unconditionally disable "diff -u" tests: use "test_cmp", not "diff", when verifying the result Do not use "diff" found on PATH while building and installing enums: omit trailing comma for portability Makefile: -lpthread may still be necessary when libc has only pthread stubs Rewrite dynamic structure initializations to runtime assignment Makefile: pass CPPFLAGS through to fllow customization Conflicts: Makefile wt-status.h
2010-06-18Merge branch 'jn/remote-set-branches'Libravatar Junio C Hamano1-11/+91
* jn/remote-set-branches: Add git remote set-branches Conflicts: builtin/remote.c
2010-05-31enums: omit trailing comma for portabilityLibravatar Gary V. Vaughan1-1/+1
Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git. enum style is inconsistent already, with some enums declared on one line, some over 3 lines with the enum values all on the middle line, sometimes with 1 enum value per line... and independently of that the trailing comma is sometimes present and other times absent, often mixing with/without trailing comma styles in a single file, and sometimes in consecutive enum declarations. Clearly, omitting the comma is the more portable style, and this patch changes all enum declarations to use the portable omitted dangling comma style consistently. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31Rewrite dynamic structure initializations to runtime assignmentLibravatar Gary V. Vaughan1-3/+6
Unfortunately, there are still plenty of production systems with vendor compilers that choke unless all compound declarations can be determined statically at compile time, for example hpux10.20 (I can provide a comprehensive list of our supported platforms that exhibit this problem if necessary). This patch simply breaks apart any compound declarations with dynamic initialisation expressions, and moves the initialisation until after the last declaration in the same block, in all the places necessary to have the offending compilers accept the code. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-19Add git remote set-branchesLibravatar Jonathan Nieder1-11/+91
Add ‘git remote set-branches’ for changing the list of tracked refs for a remote repository with one "porcelain-level" command. This complements the longstanding ‘git remote add --track’ option. The interface is based on the ‘git remote set-url’ subcommand. git remote set-branches base --add C git remote set-branches base A B D git remote set-branches base --delete D; # not implemented Suggested-by: martin f. krafft <madduck@debian.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-19remote add: add a --[no-]tags optionLibravatar Samuel Tardieu1-1/+20
Add '--[no-]tags' options to 'git remote add' which add the 'remote.REMOTE.tagopt = --[no-]tags' to the configuration file. This mimics the "--tags" and "--no-tags" options of "git fetch". Signed-off-by: Samuel Tardieu <sam@rfc1149.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+1447
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>