summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-01-31color_parse_mem: allow empty color specLibravatar Jeff King4-4/+25
Prior to c2f41bf52 (color.c: fix color_parse_mem() with value_len == 0, 2017-01-19), the empty string was interpreted as a color "reset". This was an accidental outcome, and that commit turned it into an error. However, scripts may pass the empty string as a default value to "git config --get-color" to disable color when the value is not defined. The git-add--interactive script does this. As a result, the script is unusable since c2f41bf52 unless you have color.diff.plain defined (if it is defined, then we don't parse the empty default at all). Our test scripts didn't notice the recent breakage because they run without a terminal, and thus without color. They never hit this code path at all. And nobody noticed the original buggy "reset" behavior, because it was effectively a noop. Let's fix the code to have an empty color name produce an empty sequence of color codes. The tests need a few fixups: - we'll add a new test in t4026 to cover this case. But note that we need to tweak the color() helper. While we're there, let's factor out the literal ANSI ESC character. Otherwise it makes the diff quite hard to read. - we'll add a basic sanity-check in t4026 that "git add -p" works at all when color is enabled. That would have caught this bug, as well as any others that are specific to the color code paths. - 73c727d69 (log --graph: customize the graph lines with config log.graphColors, 2017-01-19) added a test to t4202 that checks some "invalid" graph color config. Since ",, blue" before yielded only "blue" as valid, and now yields "empty, empty, blue", we don't match the expected output. One way to fix this would be to change the expectation to the empty color strings. But that makes the test much less interesting, since we show only two graph lines, both of which would be colorless. Since the empty-string case is now covered by t4026, let's remove them entirely here. They're just in the way of the primary thing the test is supposed to be checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23log --graph: customize the graph lines with config log.graphColorsLibravatar Nguyễn Thái Ngọc Duy3-3/+63
If you have a 256 colors terminal (or one with true color support), then the predefined 12 colors seem limited. On the other hand, you don't want to draw graph lines with every single color in this mode because the two colors could look extremely similar. This option allows you to hand pick the colors you want. Even with standard terminal, if your background color is neither black or white, then the graph line may match your background and become hidden. You can exclude your background color (or simply the colors you hate) with this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19color.c: trim leading spaces in color_parse_mem()Libravatar Nguyễn Thái Ngọc Duy1-1/+6
Normally color_parse_mem() is called from config parser which trims the leading spaces already. The new caller in the next patch won't. Let's be tidy and trim leading spaces too (we already trim trailing spaces after a word). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19color.c: fix color_parse_mem() with value_len == 0Libravatar Nguyễn Thái Ngọc Duy1-0/+3
In this code we want to match the word "reset". If len is zero, strncasecmp() will return zero and we incorrectly assume it's "reset" as a result. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-02Git 2.10Libravatar Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-02Merge tag 'l10n-2.10.0-rnd2.2' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano1-374/+317
l10n-2.10.0-rnd2.2 * tag 'l10n-2.10.0-rnd2.2' of git://github.com/git-l10n/git-po: l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)
2016-09-02Merge branch 'master' of https://github.com/vnwildman/gitLibravatar Jiang Xin1-374/+317
* 'master' of https://github.com/vnwildman/git: l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)
2016-08-31A few more fixes before the final 2.10Libravatar Junio C Hamano1-3/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-31Merge tag 'l10n-2.10.0-rnd2' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano8-14691/+24337
l10n-2.10.0-rnd2 * tag 'l10n-2.10.0-rnd2' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.10.0 l10n round 2 l10n: ca.po: update translation l10n: fr.po v2.10.0-rc2 l10n: sv.po: Update Swedish translation (2757t0f0u) l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed) l10n: Updated Vietnamese translation for v2.10.0 (2789t) l10n: pt_PT: update Portuguese translation l10n: pt_PT: merge git.pot l10n: ko.po: Update Korean translation l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)
2016-08-31Merge branch 'ls/packet-line-protocol-doc-fix'Libravatar Junio C Hamano1-3/+3
Correct an age-old calco (is that a typo-like word for calc) in the documentation. * ls/packet-line-protocol-doc-fix: pack-protocol: fix maximum pkt-line size
2016-08-31Merge branch 'mh/blame-worktree'Libravatar Junio C Hamano2-1/+7
* mh/blame-worktree: blame: fix segfault on untracked files
2016-08-31Merge branch 'kw/patch-ids-optim'Libravatar Junio C Hamano1-0/+0
* kw/patch-ids-optim: p3400: make test script executable
2016-08-30pack-protocol: fix maximum pkt-line sizeLibravatar Lars Schneider1-3/+3
According to LARGE_PACKET_MAX in pkt-line.h the maximal length of a pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and therefore the pkt-line data component must not exceed 65516 bytes. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-31l10n: zh_CN: for git v2.10.0 l10n round 2Libravatar Jiang Xin1-1755/+2746
Update 215 translations (2757t0f0u) for git v2.10.0-rc2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2016-08-29p3400: make test script executableLibravatar René Scharfe1-0/+0
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-29blame: fix segfault on untracked filesLibravatar Thomas Gummerer2-1/+7
Since 3b75ee9 ("blame: allow to blame paths freshly added to the index", 2016-07-16) git blame also looks at the index to determine if there is a file that was freshly added to the index. cache_name_pos returns -pos - 1 in case there is no match is found, or if the name matches, but the entry has a stage other than 0. As git blame should work for unmerged files, it uses strcmp to determine whether the name of the returned position matches, in which case the file exists, but is merely unmerged, or if the file actually doesn't exist in the index. If the repository is empty, or if the file would lexicographically be sorted as the last file in the repository, -cache_name_pos - 1 is outside of the length of the active_cache array, causing git blame to segfault. Guard against that, and die() normally to restore the old behaviour. Reported-by: Simon Ruderich <simon@ruderich.org> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-28l10n: ca.po: update translationLibravatar Alex Henrie1-2262/+3751
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
2016-08-28l10n: fr.po v2.10.0-rc2Libravatar Jean-Noel Avila1-1796/+3072
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
2016-08-28l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)Libravatar Tran Ngoc Quan1-374/+317
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2016-08-27l10n: sv.po: Update Swedish translation (2757t0f0u)Libravatar Peter Krefting1-1791/+3043
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2016-08-27Merge branch 'master' of https://github.com/vnwildman/gitLibravatar Jiang Xin1-1780/+3085
* 'master' of https://github.com/vnwildman/git: l10n: Updated Vietnamese translation for v2.10.0 (2789t)
2016-08-27l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)Libravatar Jiang Xin1-342/+189
Generate po/git.pot from v2.10.0-rc2 for git v2.10.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2016-08-27Merge branch 'master' of git://github.com/git-l10n/git-poLibravatar Jiang Xin3-5296/+8782
* 'master' of git://github.com/git-l10n/git-po: l10n: pt_PT: update Portuguese translation l10n: pt_PT: merge git.pot l10n: ko.po: Update Korean translation l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)
2016-08-27l10n: Updated Vietnamese translation for v2.10.0 (2789t)Libravatar Tran Ngoc Quan1-1780/+3085
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2016-08-26Git 2.10-rc2Libravatar Junio C Hamano2-1/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-26gitattributes: Document the unified "auto" handlingLibravatar Torsten Bögershausen1-34/+24
Update the documentation about text=auto: text=auto now follows the core.autocrlf handling when files are not normalized in the repository. For a cross platform project recommend the usage of attributes for line-ending conversions. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-25Prepare for 2.10.0-rc2Libravatar Junio C Hamano1-2/+29
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-25Merge branch 'ja/i18n'Libravatar Junio C Hamano3-71/+20
The recent i18n patch we added during this cycle did a bit too much refactoring of the messages to avoid word-legos; the repetition has been reduced to help translators. * ja/i18n: i18n: simplify numeric error reporting i18n: fix git rebase interactive commit messages i18n: fix typos for translation
2016-08-25Merge branch 'bw/mingw-avoid-inheriting-fd-to-lockfile'Libravatar Junio C Hamano6-1/+35
The tempfile (hence its user lockfile) API lets the caller to open a file descriptor to a temporary file, write into it and then finalize it by first closing the filehandle and then either removing or renaming the temporary file. When the process spawns a subprocess after obtaining the file descriptor, and if the subprocess has not exited when the attempt to remove or rename is made, the last step fails on Windows, because the subprocess has the file descriptor still open. Open tempfile with O_CLOEXEC flag to avoid this (on Windows, this is mapped to O_NOINHERIT). * bw/mingw-avoid-inheriting-fd-to-lockfile: mingw: ensure temporary file handles are not inherited by child processes t6026-merge-attr: child processes must not inherit index.lock handles
2016-08-25Merge branch 'dg/document-git-c-in-git-config-doc'Libravatar Junio C Hamano1-0/+3
The "git -c var[=val] cmd" facility to append a configuration variable definition at the end of the search order was described in git(1) manual page, but not in git-config(1), which was more likely place for people to look for when they ask "can I make a one-shot override, and if so how?" * dg/document-git-c-in-git-config-doc: doc: mention `git -c` in git-config(1)
2016-08-25Merge branch 'js/no-html-bypass-on-windows'Libravatar Junio C Hamano3-52/+0
On Windows, help.browser configuration variable used to be ignored, which has been corrected. * js/no-html-bypass-on-windows: Revert "display HTML in default browser using Windows' shell API"
2016-08-25Merge branch 'hv/doc-commit-reference-style'Libravatar Junio C Hamano1-0/+5
A small doc update. * hv/doc-commit-reference-style: SubmittingPatches: document how to reference previous commits
2016-08-25git ls-files: text=auto eol=lf is supported in Git 2.10Libravatar Torsten Bögershausen1-2/+1
The man page for `git ls-files --eol` mentions the combination of text attributes "text=auto eol=lf" or "text=auto eol=crlf" as not supported yet, but may be in the future. Now they are supported. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-25l10n: pt_PT: update Portuguese translationLibravatar Vasco Almeida1-428/+507
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
2016-08-25l10n: pt_PT: merge git.potLibravatar Vasco Almeida1-1793/+3017
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
2016-08-24i18n: simplify numeric error reportingLibravatar Jean-Noel Avila1-28/+16
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-24i18n: fix git rebase interactive commit messagesLibravatar Jean-Noel Avila1-42/+3
For proper i18n, the logic cannot embed english specific processing. Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-24i18n: fix typos for translationLibravatar Jean-Noel Avila1-1/+1
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-23doc: mention `git -c` in git-config(1)Libravatar David Glasser1-0/+3
Signed-off-by: David Glasser <glasser@davidglasser.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-23mingw: ensure temporary file handles are not inherited by child processesLibravatar Ben Wijen6-2/+23
When the index is locked and child processes inherit the handle to said lock and the parent process wants to remove the lock before the child process exits, on Windows there is a problem: it won't work because files cannot be deleted if a process holds a handle on them. The symptom: Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed. Should I try again? (y/n) Spawning child processes with bInheritHandles==FALSE would not work because no file handles would be inherited, not even the hStdXxx handles in STARTUPINFO (stdin/stdout/stderr). Opening every file with O_NOINHERIT does not work, either, as e.g. git-upload-pack expects inherited file handles. This leaves us with the only way out: creating temp files with the O_NOINHERIT flag. This flag is Windows-specific, however. For our purposes, it is equivalent to O_CLOEXEC (which does not exist on Windows), so let's just open temporary files with the O_CLOEXEC flag and map that flag to O_NOINHERIT on Windows. As Eric Wong pointed out, we need to be careful to handle the case where the Linux headers used to compile Git support O_CLOEXEC but the Linux kernel used to run Git does not: it returns an EINVAL. This fixes the test that we just introduced to demonstrate the problem. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-22l10n: ko.po: Update Korean translationLibravatar Changwoo Ryu1-1757/+2908
Signed-off-by: Changwoo Ryu <cwryu@debian.org>
2016-08-19Git 2.10-rc1Libravatar Junio C Hamano2-1/+32
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-19Merge branch 'lt/gpg-show-long-key-in-signature-verification'Libravatar Junio C Hamano1-0/+1
"git log --show-signature" and other commands that display the verification status of PGP signature now shows the longer key-id, as 32-bit key-id is so last century. * lt/gpg-show-long-key-in-signature-verification: gpg-interface: prefer "long" key format output when verifying pgp signatures
2016-08-19Merge branch 'ab/hooks'Libravatar Junio C Hamano3-4/+9
"git rev-parse --git-path hooks/<hook>" learned to take core.hooksPath configuration variable (introduced during 2.9 cycle) into account. * ab/hooks: rev-parse: respect core.hooksPath in --git-path
2016-08-19Merge branch 'jk/difftool-command-not-found'Libravatar Junio C Hamano2-0/+13
"git difftool" by default ignores the error exit from the backend commands it spawns, because often they signal that they found differences by exiting with a non-zero status code just like "diff" does; the exit status codes 126 and above however are special in that they are used to signal that the command is not executable, does not exist, or killed by a signal. "git difftool" has been taught to notice these exit status codes. * jk/difftool-command-not-found: difftool: always honor fatal error exit codes
2016-08-19Merge branch 'sb/checkout-explit-detach-no-advice'Libravatar Junio C Hamano2-1/+25
"git checkout --detach <branch>" used to give the same advice message as that is issued when "git checkout <tag>" (or anything that is not a branch name) is given, but asking with "--detach" is an explicit enough sign that the user knows what is going on. The advice message has been squelched in this case. * sb/checkout-explit-detach-no-advice: checkout: do not mention detach advice for explicit --detach option
2016-08-19Merge branch 'tb/t0027-raciness-fix'Libravatar Junio C Hamano2-43/+60
The t0027 test for CRLF conversion was timing dependent and flaky. * tb/t0027-raciness-fix: convert: Correct NNO tests and missing `LF will be replaced by CRLF`
2016-08-19Merge branch 'rs/pull-signed-tag'Libravatar Junio C Hamano4-12/+33
When "git merge-recursive" works on history with many criss-cross merges in "verbose" mode, the names the command assigns to the virtual merge bases could have overwritten each other by unintended reuse of the same piece of memory. * rs/pull-signed-tag: commit: use FLEX_ARRAY in struct merge_remote_desc merge-recursive: fix verbose output for multiple base trees commit: factor out set_merge_remote_desc() commit: use xstrdup() in get_merge_parent()
2016-08-19Revert "display HTML in default browser using Windows' shell API"Libravatar Johannes Schindelin3-52/+0
Since 4804aab (help (Windows): Display HTML in default browser using Windows' shell API, 2008-07-13), Git for Windows used to call `ShellExecute()` to launch the default Windows handler for `.html` files. The idea was to avoid going through a shell script, for performance reasons. However, this change ignores the `help.browser` config setting. Together with browsing help not being a performance-critical operation, let's just revert that patch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-18t6026-merge-attr: child processes must not inherit index.lock handlesLibravatar Ben Wijen1-0/+13
On Windows, a file cannot be removed unless all file handles to it have been released. Hence it is particularly important to close handles when spawning children (which would probably not even know that they hold on to those handles). The example chosen for this test is a custom merge driver that indeed has no idea that it blocks the deletion of index.lock. The full use case is a daemon that lives on after the merge, with subsequent invocations handing off to the daemon, thereby avoiding hefty start-up costs. We simulate this behavior by simply sleeping one second. Note that the test only fails on Windows, due to the file locking issue. Since we have no way to say "expect failure with MINGW, success otherwise", we simply skip this test on Windows for now. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>