- 17 1月, 2013 1 次提交
-
-
由 Max Horn 提交于
Commit a469a101 wraps some error calls in macros to give the compiler a chance to do more static analysis on their constant -1 return value. We limit the use of these macros to __GNUC__, since gcc is the primary beneficiary of the new information, and because we use GNU features for handling variadic macros. However, clang also defines __GNUC__, but generates warnings with -Wunused-value when these macros are used in a void context, because the constant "-1" ends up being useless. Gcc does not complain about this case (though it is unclear if it is because it is smart enough to see what we are doing, or too dumb to realize that the -1 is unused). We can squelch the warning by just disabling these macros when clang is in use. Signed-off-by: NMax Horn <max@quendi.de> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 12月, 2012 3 次提交
-
-
由 Jeff King 提交于
There are a few error functions that simply wrap error() and provide a standardized message text. Like error(), they always return -1; knowing that can help the compiler silence some false positive -Wuninitialized warnings. One strategy would be to just declare these as inline in the header file so that the compiler can see that they always return -1. However, gcc does not always inline them (e.g., it will not inline opterror, even with -O3), which renders our change pointless. Instead, let's follow the same route we did with error() in the last patch, and define a macro that makes the constant return value obvious to the compiler. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When git is compiled with "gcc -Wuninitialized -O3", some inlined calls provide an additional opportunity for the compiler to do static analysis on variable initialization. For example, with two functions like this: int get_foo(int *foo) { if (something_that_might_fail() < 0) return error("unable to get foo"); *foo = 0; return 0; } void some_fun(void) { int foo; if (get_foo(&foo) < 0) return -1; printf("foo is %d\n", foo); } If get_foo() is not inlined, then when compiling some_fun, gcc sees only that a pointer to the local variable is passed, and must assume that it is an out parameter that is initialized after get_foo returns. However, when get_foo() is inlined, the compiler may look at all of the code together and see that some code paths in get_foo() do not initialize the variable. As a result, it prints a warning. But what the compiler can't see is that error() always returns -1, and therefore we know that either we return early from some_fun, or foo ends up initialized, and the code is safe. The warning is a false positive. If we can make the compiler aware that error() will always return -1, it can do a better job of analysis. The simplest method would be to inline the error() function. However, this doesn't work, because gcc will not inline a variadc function. We can work around this by defining a macro. This relies on two gcc extensions: 1. Variadic macros (these are present in C99, but we do not rely on that). 2. Gcc treats the "##" paste operator specially between a comma and __VA_ARGS__, which lets our variadic macro work even if no format parameters are passed to error(). Since we are using these extra features, we hide the macro behind an #ifdef. This is OK, though, because our goal was just to help gcc. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
In remote-test-svn, there is a parse_rev_note function to parse lines of the form "Revision-number" from notes. If it finds such a line and parses it, it returns 0, copying the value into a "struct rev_note". If it finds an entry that is garbled or out of range, it returns -1 to signal an error. However, if it does not find any "Revision-number" line at all, it returns success but does not put anything into the rev_note. So upon a successful return, the rev_note may or may not be initialized, and the caller has no way of knowing. gcc does not usually catch the use of the unitialized variable because the conditional assignment happens in a separate function from the point of use. However, when compiling with -O3, gcc will inline parse_rev_note and notice the problem. We can fix it by returning "-1" when no note is found (so on a zero return, we always found a valid value). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 12月, 2012 4 次提交
-
-
由 Junio C Hamano 提交于
-
由 Matthew Daley 提交于
Currently it gets the size of an otherwise unrelated, unused variable instead of the expected struct size. Signed-off-by: NMatthew Daley <mattjd@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* mh/doc-remote-helpers: git-remote-helpers.txt: clarify options & ref list attributes git-remote-helpers.txt: clarify command <-> capability correspondences git-remote-helpers.txt: rearrange description of capabilities git-remote-helpers.txt: minor grammar fix git-remote-helpers.txt: document missing capabilities git-remote-helpers.txt: document invocation before input format
-
由 Manlio Perillo 提交于
Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE), the Documentation/git.txt file did not mention that the GIT_DIR environment variable can also be set using the --git-dir command line option. Signed-off-by: NManlio Perillo <manlio.perillo@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 12月, 2012 3 次提交
-
-
由 Junio C Hamano 提交于
We earlier removed a link to list of contributors that pointed to a defunct page; let's use a working one from Ohloh.net to replace it instead. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* so/prompt-command: git-prompt.sh: update PROMPT_COMMAND documentation
-
由 Junio C Hamano 提交于
The description of __git_ps1 function operating in two-arg mode was not very clear. It said "set PROMPT_COMMAND=__git_ps1" which is not the right usage for this mode, followed by "To customize the prompt, do this", giving a false impression that those who do not want to customize it can get away with no-arg form, which was incorrect. Make it clear that this mode always takes two arguments, pre and post, with an example. The straight-forward one should be listed as the primary usage, and the confusing one should be an alternate for advanced users. Swap the order of these two. Acked-by: NSimon Oosthoek <s.oosthoek@xs4all.nl> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 12月, 2012 5 次提交
-
-
由 Marc Khouzam 提交于
For bash completion, the option '-o bashdefault' is used to indicate that when no other choices are available, file completion should be performed. Since this option is not available in tcsh, no file completion is ever performed. Therefore, commands like 'git add ', 'git send-email ', etc, require the user to manually type out the file name. This can be quite annoying. To improve the user experience we try to simulate file completion directly in this script (although not perfectly). The known issues with the file completion simulation are: - Possible completions are shown with their directory prefix. - Completions containing shell variables are not handled. - Completions with ~ as the first character are not handled. Signed-off-by: NMarc Khouzam <marc.khouzam@ericsson.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
MinGW has a workaround when rmdir unnecessarily fails to retry with a prompt, but the logic was kicking in when the rmdir failed with ENOTEMPTY, i.e. was expected to fail and there is no point retrying. * ef/mingw-rmdir: mingw_rmdir: do not prompt for retry when non-empty
-
由 Junio C Hamano 提交于
Update getpass() emulation for MinGW. * ef/mingw-tty-getpass: mingw: get rid of getpass implementation mingw: reuse tty-version of git_terminal_prompt compat/terminal: separate input and output handles compat/terminal: factor out echo-disabling mingw: make fgetc raise SIGINT if apropriate mingw: correct exit-code for SIGALRM's SIG_DFL
-
由 Junio C Hamano 提交于
* maint: git-prompt: Document GIT_PS1_DESCRIBE_STYLE
-
由 Anders Kaseorg 提交于
GIT_PS1_DESCRIBE_STYLE was introduced in v1.6.3.2~35. Document it in the header comments. Signed-off-by: NAnders Kaseorg <andersk@mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 12月, 2012 5 次提交
-
-
由 Junio C Hamano 提交于
* maint: Git 1.8.0.2 Documentation/git-stash.txt: add a missing verb git(1): remove a defunct link to "list of authors" Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stefano Lattarini 提交于
Consistently use a single space before and after the "=" (or ":=", "+=", etc.) in assignments to make macros. Granted, this was not a big deal, but I did find the needless inconsistency quite distracting. Signed-off-by: NStefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Erik Faye-Lund 提交于
in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"), a check was added to prevent us from retrying to delete a directory that is both in use and non-empty. However, this logic was slightly flawed; since we didn't return immediately, we end up falling out of the retry-loop, but right into the prompting-loop. Fix this by setting errno, and guarding the prompting-loop with an errno-check. Signed-off-by: NErik Faye-Lund <kusmabite@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Sébastien Loriot 提交于
Signed-off-by: NSébastien Loriot <sloriot.ml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 12月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
The linked page has not been showing the promised "more complete list" for more than 6 months by now, and nobody has resurrected the list there nor elsewhere since then. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 12月, 2012 15 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The line that happens to begin with indent followed by "3. " was interpreted as if it was an enumerated list; just wrap the lines differently to work it around for now. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* maint: Update draft release notes to 1.8.0.2
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* jc/doc-push-satellite: Documentation/git-push.txt: clarify the "push from satellite" workflow
-
由 Junio C Hamano 提交于
Various codepaths checked if two encoding names are the same using ad-hoc code and some of them ended up asking iconv() to convert between "utf8" and "UTF-8". The former is not a valid way to spell the encoding name, but often people use it by mistake, and we equated them in some but not all codepaths. Introduce a new helper function to make these codepaths consistent. * jc/same-encoding: reencode_string(): introduce and use same_encoding()
-
由 Junio C Hamano 提交于
"git diff --stat" miscounted the total number of changed lines when binary files were involved and hidden beyond --stat-count. It also miscounted the total number of changed files when there were unmerged paths. * lt/diff-stat-show-0-lines: t4049: refocus tests diff --shortstat: do not count "unmerged" entries diff --stat: do not count "unmerged" entries diff --stat: move the "total count" logic to the last loop diff --stat: use "file" temporary variable to refer to data->files[i] diff --stat: status of unmodified pair in diff-q is not zero test: add failing tests for "diff --stat" to t4049 Fix "git diff --stat" for interesting - but empty - file changes
-
由 Max Horn 提交于
The documentation was misleading in that it gave the impression that 'for-push' could be used as a ref attribute in the output of the 'list' command. That is wrong. Also, explicitly point out the connection between the commands 'list' and 'options' on the one hand, and the sections 'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand. Signed-off-by: NMax Horn <max@quendi.de> Acked-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Max Horn 提交于
In particular, document 'list for-push' separately from 'list', as the former needs only be supported for the push/export capabilities, and the latter only for fetch/import. Indeed, a hypothetically 'push-only' helper would only need to support the former, not the latter. Signed-off-by: NMax Horn <max@quendi.de> Acked-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Max Horn 提交于
This also remove some duplication in the descriptions (e.g. refspec was explained twice with similar level of detail). Signed-off-by: NMax Horn <max@quendi.de> Acked-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Max Horn 提交于
Signed-off-by: NMax Horn <max@quendi.de> Acked-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Max Horn 提交于
Specifically, document the 'export' and '(im|ex)port-marks' capabilities as well as the export command, which were undocumented (but in active use). Signed-off-by: NMax Horn <max@quendi.de> Acked-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Max Horn 提交于
In the distant past, the order things were documented was 'Invocation', 'Commands', 'Capabilities', ... Then it was decided that before giving a list of Commands, there should be an overall description of the 'Input format', which was a wise decision. However, this description was put as the very first thing, with the rationale that any implementor would want to know that first. However, it seems an implementor would actually first need to know how the remote helper will be invoked, so moving 'Invocation' to the front again seems logical. Moreover, we now don't switch from discussing the input format to the invocation style and then back to input related stuff. Signed-off-by: NMax Horn <max@quendi.de> Acked-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
git://github.com/git-l10n/git-po由 Junio C Hamano 提交于
* 'master' of git://github.com/git-l10n/git-po: l10n: de.po: translate 22 new messages l10n: de.po: translate 825 new messages l10n: Update Swedish translation (1979t0f0u) l10n: vi.po: update to git-v1.8.0.1-347-gf94c3 l10n: Update git.pot (5 new, 1 removed messages)
-
由 Junio C Hamano 提交于
* rr/t4041-cleanup: t4041 (diff-submodule-option): modernize style t4041 (diff-submodule-option): rewrite add_file() routine t4041 (diff-submodule-option): parse digests sensibly t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
-
- 07 12月, 2012 1 次提交
-
-
git://github.com/ralfth/git-po-de由 Jiang Xin 提交于
* 'rt/de-l10n-updates-for-1.8.1' of git://github.com/ralfth/git-po-de: l10n: de.po: translate 22 new messages l10n: de.po: translate 825 new messages Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
-
- 06 12月, 2012 2 次提交
-
-
由 Ralf Thielow 提交于
Translate 22 new messages came from git.pot updates in 9306b5b9 (l10n: Update git.pot (3 new, 6 removed messages)), fe52cd62 (l10n: Update git.pot (14 new, 3 removed messages)) and f9472e35 (l10n: Update git.pot (5 new, 1 removed messages)). Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com> Reviewed-by: NMichael J Gruber <git@drmicha.warpmail.net>
-
由 Ralf Thielow 提交于
Translate 825 new messages came from git.pot update in cc76011e ("l10n: Update git.pot (825 new, 24 removed messages)"). Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com> Reviewed-by: NThomas Rast <trast@student.ethz.ch> Helped-by: NMichael J Gruber <git@drmicha.warpmail.net>
-