user/sven/git.git/help.c, branch v1.7.7.4

Merge branch 'ms/help-unknown'

2011-07-22T21:43:21Z

* ms/help-unknown: help_unknown_cmd: do not propose an "unknown" cmd

help_unknown_cmd: do not propose an "unknown" cmd

2011-07-08T15:59:44Z

When executing an external shell script like `git foo` with a bad shebang, e.g. "#!/usr/bin/not/existing", execvp returns 127 (ENOENT). Since help_unknown_cmd proposes the use of all external commands similar to the name of the "unknown" command, it suggests the just failed command again. Stop it and give some advice to the user. Helped-by: Jeff King Signed-off-by: Michael Schubert Signed-off-by: Junio C Hamano

help.c: Fix detection of custom merge strategy on cygwin

2011-06-16T22:02:31Z

Test t7606-merge-custom.sh fails on cygwin when git-merge fails with an "Could not find merge strategy 'theirs'" error, despite the test correctly preparing an (executable) git-merge-theirs script. The cause of the failure is the mis-detection of the executable status of the script, by the is_executable() function, while the load_command_list() function is searching the path for additional merge strategy programs. Note that the l/stat() "functions" on cygwin are somewhat schizophrenic (see commits adbc0b6, 7faee6b and 7974843), and their behaviour depends on the timing of various git setup and config function calls. In particular, until the "git_dir" has been set (have_git_dir() returns true), the real cygwin (POSIX emulating) l/stat() functions are called. Once "git_dir" has been set, the "native Win32 API" implementations of l/stat() may, or may not, be called depending on the setting of the core.filemode and core.ignorecygwinfstricks config variables. We also note that, since commit c869753, core.filemode is forced to false, even on NTFS, by git-init and git-clone. A user (or a test) can, of course, reset core.filemode to true explicitly if the filesystem supports it (and he doesn't use any problematic windows software). The test-suite currently runs all tests on cygwin with core.filemode set to false. Given the above, we see that the built-in merge strategies are correctly detected as executable, since they are checked for before "git_dir" is set, whereas all custom merge strategies are not, since they are checked for after "git_dir" is set. In order to fix the mis-detection problem, we change the code in is_executable() to re-use the conditional WIN32 code section, which actually looks at the content of the file to determine if the file is executable. On cygwin we also make the additional code conditional on the executable bit of the file mode returned by the initial stat() call. (only the real cygwin function would set the executable bit in the file mode.) Signed-off-by: Ramsay Jones Signed-off-by: Junio C Hamano

help: always suggest common-cmds if prefix of cmd

2010-12-05T20:15:12Z

If someone runs "git st", the command "git status" is not suggested because it's not one of the closest levenshtein-neighbour. Reserve the distance of 0 for common commands where the entered command is a prefixe, as these are often more likely to be what the user meant. This way, "git status" is the first suggestion, while a list of possible typos are still suggested as well. Signed-off-by: Erik Faye-Lund Signed-off-by: Junio C Hamano

Remove hyphen from "git-command" in two error messages

2010-02-16T02:20:54Z

Signed-off-by: Pete Harlan Signed-off-by: Junio C Hamano

help.autocorrect: do not run a command if the command given is junk

2009-12-16T00:21:51Z

If a given command is not found, then help.c tries to guess which one the user could have meant. If help.autocorrect is 0 or unset, then a list of suggestions is given as long as the dissimilarity between the given command and the candidates is not excessively high. But if help.autocorrect was non-zero (i.e., a delay after which the command is run automatically), the latter restriction on dissimilarity was not obeyed. In my case, this happened: $ git ..daab02 WARNING: You called a Git command named '..daab02', which does not exist. Continuing under the assumption that you meant 'read-tree' in 4.0 seconds automatically... The patch reuses the similarity limit that is also applied when the list of suggested commands is printed. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

Test for WIN32 instead of __MINGW32_

2009-09-19T03:00:42Z

The code which is conditional on MinGW32 is actually conditional on Windows. Use the WIN32 symbol, which is defined by the MINGW32 and MSVC environments, but not by Cygwin. Define SNPRINTF_SIZE_CORR=1 for MSVC too, as its vsnprintf function does not add NUL at the end of the buffer if the result fits the buffer size exactly. Signed-off-by: Frank Li Signed-off-by: Marius Storm-Olsen Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Avoid declaration after statement

2009-09-19T03:00:41Z

MSVC does not understand this C99 style. Signed-off-by: Frank Li Signed-off-by: Marius Storm-Olsen Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'maint-1.6.3' into maint

2009-08-12T23:15:55Z

* maint-1.6.3: Change mentions of "git programs" to "git commands" Documentation: merge: one is required help.c: give correct structure's size to memset()

Change mentions of "git programs" to "git commands"

2009-08-12T23:14:41Z

Most of the docs and printouts refer to "commands" when discussing what the end users call via the "git" top-level program. We should refer them as "git programs" when we discuss the fact that the commands are implemented as separate programs, but in other contexts, it is better to use the term "git commands" consistently. Signed-off-by: Ori Avtalion Signed-off-by: Nanako Shiraishi Signed-off-by: Junio C Hamano