- 09 10月, 2010 1 次提交
-
-
由 Štěpán Němec 提交于
Remove some stray usage of other bracket types and asterisks for the same purpose. Signed-off-by: NŠtěpán Němec <stepnem@gmail.com> Acked-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 9月, 2010 1 次提交
-
-
由 Brandon Casey 提交于
Save future readers the trouble of tracing code to determine that the two uses of branch->remote_name are safe when has_merge is set, by adding a comment explaining that it is so. Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 8月, 2010 1 次提交
-
-
由 Brandon Casey 提交于
When 'git fetch' is supplied a single argument, it tries to match it against a configured remote and then fetch the refs specified by the named remote's fetchspec. Additionally, or alternatively, if the current branch has a merge ref configured, and if the name of the remote supplied to fetch matches the one in the branch's configuration, then git also adds the merge ref to the list of refs to update. If the argument to fetch does not specify a named remote, or if the name supplied does not match the remote configured for the current branch, then the current branch's merge configuration should not be considered. git currently mishandles the case when the argument to fetch specifies a GIT URL(i.e. not a named remote) and the current branch has a configured merge ref. In this case, fetch should ignore the branch's merge ref and attempt to fetch from the remote repository's HEAD branch. But, since fetch only checks _whether_ the current branch has a merge ref configured, and does _not_ check whether the branch's configured remote matches the command line argument (until later), it will mistakenly enter the wrong branch of an 'if' statement and will not fall back to fetch the HEAD branch. The fetch ends up doing nothing and returns with a successful zero status. Fix this by comparing the remote repository's name to the branch's remote name, in addition to whether it has a configured merge ref, sooner, so that fetch can correctly decide whether the branch's configuration is interesting or not, and fall back to fetching from the remote's HEAD branch when appropriate. This fixes the test in t5510. Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 8月, 2010 1 次提交
-
-
由 Daniel Johnson 提交于
Originally, if remote.<name>.tagopt was set, the --tags and option would have no effect when given to git fetch. So if tagopt="--no-tags" git fetch --tags would not actually fetch tags. This patch changes this behavior to only follow what is written in the config if there is no option passed by the command line. Signed-off-by: NDaniel Johnson <ComputerDruid@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 7月, 2010 1 次提交
-
-
由 Matthieu Moy 提交于
The message is especially confusing when "git fetch" is ran from "git pull", for users not aware of "git fetch". The new message makes it clear that "fetch" means "fetch new revisions", and gives hint on the solution. We don't add a advice.* configuration option since this message doesn't appear in normal use, and shouldn't disturb advanced users. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 7月, 2010 2 次提交
-
-
由 Thiago Farina 提交于
Acked-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NThiago Farina <tfransosi@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Alex Riesen 提交于
The rule for selecting the candidates for conversion is: if the callback function returns only 0 (the condition for for_each_string_list to exit early), than it can be safely converted to the macro. A notable exception are the callers in builtin/remote.c. If converted, the readability in the file will suffer greately. Besides, the code is not very performance critical (at the moment, at least): it does output formatting of the list of remotes. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 6月, 2010 4 次提交
-
-
由 Julian Phillips 提交于
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: NJulian Phillips <julian@quantumfyre.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Julian Phillips 提交于
Update the definition and callers of string_list_lookup 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: NJulian Phillips <julian@quantumfyre.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Julian Phillips 提交于
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: NJulian Phillips <julian@quantumfyre.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Julian Phillips 提交于
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: NJulian Phillips <julian@quantumfyre.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 6月, 2010 1 次提交
-
-
由 Gary V. Vaughan 提交于
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: NGary V. Vaughan <gary@thewrittenword.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2010 1 次提交
-
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 2月, 2010 1 次提交
-
-
由 Michael Lukashov 提交于
The following functions are (almost) identical: verify_remote_names update_tracking_ref refs_pushed print_push_status Move common versions of these functions to transport.c and rename them, as suggested by Jeff King and Junio C Hamano. These functions have been removed entirely from builtin-send-pack.c, since they are only used internally by print_push_status(): print_ref_status status_abbrev print_ok_ref_status print_one_push_status Also, move #define SUMMARY_WIDTH to transport.h and rename it TRANSPORT_SUMMARY_WIDTH as it is used in builtin-fetch.c and transport.c Signed-off-by: NMichael Lukashov <michael.lukashov@gmail.com> Acked-by: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 11月, 2009 1 次提交
-
-
由 Daniel Barkalow 提交于
For fetch and ls-remote, which use the first url of a remote, have transport_get() determine this by passing a remote and passing NULL for the url. For push, which uses every url of a remote, use each url in turn if there are any, and use NULL if there are none. This will allow the transport code to do something different if the location is not specified with a url. Also, have the message for a fetch say "foreign" if there is no url. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 11月, 2009 5 次提交
-
-
由 Jay Soffian 提交于
Teach fetch --dry-run as users of "git remote prune" switching to "git fetch --prune" may expect it. Unfortunately OPT__DRY_RUN() cannot be used as fetch already uses "-n" for something else. Signed-off-by: NJay Soffian <jaysoffian@gmail.com> Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jay Soffian 提交于
Teach fetch to cull stale remote tracking branches after fetching via --prune. Signed-off-by: NJay Soffian <jaysoffian@gmail.com> Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Björn Gustavsson 提交于
Implement the configuration skipFetchAll option to allow certain remotes to be skipped when doing 'git fetch --all' and 'git remote update'. The existing skipDefaultUpdate variable is still honored (by 'git fetch --all' and 'git remote update'). (If both are set in the configuration file with different values, the value of the last occurrence will be used.) Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Björn Gustavsson 提交于
Add the --multiple option to specify that all arguments are either groups or remotes. The primary reason for adding this option is to allow us to re-implement 'git remote update' using fetch. It would have been nice if this option was not needed, but since the colon in a refspec is optional, it is in general not possible to know whether a single, colon-less argument is a remote or a refspec. Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Björn Gustavsson 提交于
'git remote' is meant for managing remotes and 'git fetch' is meant for actually fetching data from remote repositories. Therefore, it is not logical that you must use 'git remote update' to fetch from more than one repository at once. Add the --all option to 'git fetch', to tell it to attempt to fetch from all remotes. Also, if --all is not given, the <repository> argument is allowed to be the name of a group, to allow fetching from all repositories in the group. Other options except -v and -q are silently ignored. Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 10月, 2009 1 次提交
-
-
由 Shawn O. Pearce 提交于
Helpers might want a higher level of verbosity than just +1 (the porcelain default setting) and +2 (-v -v). Expand the field to allow verbosity in the range -1..3. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> CC: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 10月, 2009 1 次提交
-
-
由 Julian Phillips 提交于
When there are large numbers of refs, calling read_ref for each ref is inefficent (and infact downright slow) - so instead use for_each_ref to build up a string list of all the refs that we currently have, which significantly improves the volume. Signed-off-by: NJulian Phillips <julian@quantumfyre.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 10月, 2009 1 次提交
-
-
由 Felipe Contreras 提交于
It's a compound word. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 9月, 2009 1 次提交
-
-
由 Julian Phillips 提交于
When trying to get a list of remote tags to see if we need to fetch any we were doing a linear search for the matching tag ref for the tag^{} commit entries. This proves to be incredibly slow for large numbers of tags. Rewrite the function so that we build up a string_list of refs to fetch and then process that instead. As an extreme example, for a repository with 50000 tags (and just a single commit on a single branch), a fetch that does nothing goes from ~1m50s to ~4.1s. Signed-off-by: NJulian Phillips <julian@quantumfyre.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 9月, 2009 1 次提交
-
-
由 Jim Meyering 提交于
In 2d14d65c (Use a clearer style to issue commands to remote helpers, 2009-09-03) I happened to notice two changes like this: - write_in_full(helper->in, "list\n", 5); + + strbuf_addstr(&buf, "list\n"); + write_in_full(helper->in, buf.buf, buf.len); + strbuf_reset(&buf); IMHO, it would be better to define a new function, static inline ssize_t write_str_in_full(int fd, const char *str) { return write_in_full(fd, str, strlen(str)); } and then use it like this: - strbuf_addstr(&buf, "list\n"); - write_in_full(helper->in, buf.buf, buf.len); - strbuf_reset(&buf); + write_str_in_full(helper->in, "list\n"); Thus not requiring the added allocation, and still avoiding the maintenance risk of literal string lengths. These days, compilers are good enough that strlen("literal") imposes no run-time cost. Transformed via this: perl -pi -e \ 's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\ $(git grep -l 'write_in_full.*"') Signed-off-by: NJim Meyering <meyering@redhat.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 7月, 2009 1 次提交
-
-
由 Johan Herland 提交于
quickfetch() calls rev-list to check whether the objects we are about to fetch are already present in the repo (if so, we can skip the object fetch). However, when there are many (~1000) refs to be fetched, the rev-list command line grows larger than the maximum command line size on some systems (32K in Windows). This causes rev-list to fail, making quickfetch() return non-zero, which unnecessarily triggers the transport machinery. This somehow causes fetch to fail with an exit code. By using the --stdin option to rev-list (and feeding the object list to its standard input), we prevent the overflow of the rev-list command line, which causes quickfetch(), and subsequently the overall fetch, to succeed. However, using rev-list --stdin is not entirely straightforward: rev-list terminates immediately when encountering an unknown object, which can trigger SIGPIPE if we are still writing object's to its standard input. We therefore temporarily ignore SIGPIPE so that the fetch process is not terminated. The patch also contains a testcase to verify the fix (note that before the patch, the testcase would only fail on msysGit). Signed-off-by: NJohan Herland <johan@herland.net> Improved-by: NJohannes Sixt <j6t@kdbg.org> Improved-by: NAlex Riesen <raa.lkml@gmail.com> Tested-by: NPeter Krefting <peter@softwolves.pp.se> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 5月, 2009 1 次提交
-
-
由 Jeff King 提交于
When we fail to store a fetched ref, we recommend that the user try running "git prune" to remove up any old refs that have been deleted by the remote, which would clear up any DF conflicts. However, ref storage might fail for other reasons (e.g., permissions problems) in which case the advice is useless and misleading. This patch detects when there is an actual DF situation and only issues the advice when one is found. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 5月, 2009 1 次提交
-
-
由 Stephen Boyd 提交于
To give OPT_FILENAME the prefix, we pass the prefix to parse_options() which passes the prefix to parse_options_start() which sets the prefix member of parse_opts_ctx accordingly. If there isn't a prefix in the calling context, passing NULL will suffice. Signed-off-by: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 5月, 2009 2 次提交
-
-
由 Felipe Contreras 提交于
In preparation to be used when the ref object is not available Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Acked-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Alex Riesen 提交于
The fmt-merge-msg does a strong syntax checking of its input and fails with if it is incorrect. The LF character is the only character important for fmt-merge-msg. As the url in FETCH_HEAD plays only informational role, a quoted representation of the url should be good and true enough. The url often comes from either user-editable config or command line, so it is reasonable to expect all kinds of characters in it, including the characters which the format of FETCH_HEAD considers special (line separator in this case). Noticed and reported by Hugo Mildenberger. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 4月, 2009 1 次提交
-
-
由 Andreas Ericsson 提交于
When pulling from a remote, the full URL including username is by default added to the commit message. Since it adds very little value but could be used by malicious people to glean valid usernames (with matching hostnames), we're far better off just stripping the username before storing the remote URL locally. Note that this patch has no lasting visible effect when "git pull" does not create a merge commit. It simply alters what gets written to .git/FETCH_HEAD, which is used by "git merge" to automagically create its messages. Signed-off-by: NAndreas Ericsson <ae@op5.se> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 3月, 2009 1 次提交
-
-
由 Alex Riesen 提交于
Otherwise, it is hard to guess why the fetch failed. Make sure we at least mention that the repository must be bare. Also the current branch is printed. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 3月, 2009 1 次提交
-
-
由 Daniel Barkalow 提交于
When there's no explicitly-named remote, we use the remote specified for the current branch, which in turn defaults to "origin". But it this case should require the remote to actually be configured, and not fall back to the path "origin". Possibly, the config file's "remote = something" should require the something to be a configured remote instead of a bare repository URL, but we actually test with a bare repository URL. In fetch, we were giving the sensible error message when coming up with a URL failed, but this wasn't actually reachable, so move that error up and use it when appropriate. In push, we need a new error message, because the old one (formerly unreachable without a lot of help) used the repo name, which was NULL. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 3月, 2009 1 次提交
-
-
由 Daniel Barkalow 提交于
The result should be consistent between fetch and push, so we ought to use the same code in both cases, even though it's short. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 1月, 2009 2 次提交
-
-
由 Jeff King 提交于
The current code is very inconsistent about which signals are caught for doing cleanup of temporary files and lock files. Some callsites checked only SIGINT, while others checked a variety of death-dealing signals. This patch factors out those signals to a single function, and then calls it everywhere. For some sites, that means this is a simple clean up. For others, it is an improvement in that they will now properly clean themselves up after a larger variety of signals. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
If a piece of code wanted to do some cleanup before exiting (e.g., cleaning up a lockfile or a tempfile), our usual strategy was to install a signal handler that did something like this: do_cleanup(); /* actual work */ signal(signo, SIG_DFL); /* restore previous behavior */ raise(signo); /* deliver signal, killing ourselves */ For a single handler, this works fine. However, if we want to clean up two _different_ things, we run into a problem. The most recently installed handler will run, but when it removes itself as a handler, it doesn't put back the first handler. This patch introduces sigchain, a tiny library for handling a stack of signal handlers. You sigchain_push each handler, and use sigchain_pop to restore whoever was before you in the stack. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 1月, 2009 1 次提交
-
-
由 Alexander Potashev 提交于
LF at the end of format strings given to die() is redundant because die already adds one on its own. Signed-off-by: NAlexander Potashev <aspotashev@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 11月, 2008 1 次提交
-
-
由 Tuncer Ayaz 提交于
Implement git-pull --quiet and git-pull --verbose by adding the options to git-pull and fixing verbosity handling in git-fetch. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 10月, 2008 1 次提交
-
-
由 René Scharfe 提交于
With all calls to alloc_ref() gone, we can remove it and then we're free to give alloc_ref_from_str() the shorter name. It's a much nicer interface, as the callers always need to have a name string when they allocate a ref anyway and don't need to calculate and pass its length+1 any more. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 10月, 2008 1 次提交
-
-
由 Johannes Schindelin 提交于
Some confusing tutorials suggested that it would be a good idea to fetch into the current branch with something like this: git fetch origin master:master (or even worse: the same command line with "pull" instead of "fetch"). While it might make sense to store what you want to pull, it typically is plain wrong when the current branch is "master". This should only be allowed when (an incorrect) "git pull origin master:master" tries to work around by giving --update-head-ok to underlying "git fetch", and otherwise we should refuse it, but somewhere along the lines we lost that behavior. The check for the current branch is now _only_ performed in non-bare repositories, which is an improvement from the original behaviour. Some newer tests were depending on the broken behaviour of "git fetch" this patch fixes, and have been adjusted. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Acked-by: NShawn O. Pearce <spearce@spearce.org> Acked-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-