summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-06-25Merge branch 'rs/mailinfo-header-cmp' into maintLibravatar Junio C Hamano1-3/+3
"git mailinfo" used to read beyond the end of header string while parsing an incoming e-mail message to extract the patch. * rs/mailinfo-header-cmp: mailinfo: use strcmp() for string comparison
2014-06-25Merge branch 'jk/index-pack-report-missing' into maintLibravatar Junio C Hamano1-2/+7
The error reporting from "git index-pack" has been improved to distinguish missing objects from type errors. * jk/index-pack-report-missing: index-pack: distinguish missing objects from type errors
2014-06-25Merge branch 'nd/index-pack-one-fd-per-thread' into maintLibravatar Junio C Hamano3-18/+17
We used to disable threaded "git index-pack" on platforms without thread-safe pread(); use a different workaround for such platforms to allow threaded "git index-pack". * nd/index-pack-one-fd-per-thread: index-pack: work around thread-unsafe pread()
2014-06-25Merge branch 'sk/spawn-less-case-insensitively-from-grep-O-i' into maintLibravatar Junio C Hamano1-0/+3
"git grep -O" to show the lines that hit in the pager did not work well with case insensitive search. We now spawn "less" with its "-I" option when it is used as the pager (which is the default). * sk/spawn-less-case-insensitively-from-grep-O-i: git grep -O -i: if the pager is 'less', pass the '-I' option
2014-06-25Merge branch 'nd/daemonize-gc' into maintLibravatar Junio C Hamano1-6/+20
"git gc --auto" was recently changed to run in the background to give control back early to the end-user sitting in front of the terminal, but it forgot that housekeeping involving reflogs should be done without other processes competing for accesses to the refs. * nd/daemonize-gc: gc --auto: do not lock refs in the background
2014-06-25Merge branch 'jk/diff-follow-must-take-one-pathspec' into maintLibravatar Junio C Hamano2-6/+5
"git format-patch" did not enforce the rule that the "--follow" option from the log/diff family of commands must be used with exactly one pathspec. * jk/diff-follow-must-take-one-pathspec: move "--follow needs one pathspec" rule to diff_setup_done
2014-06-25Merge branch 'jk/diff-files-assume-unchanged' into maintLibravatar Junio C Hamano2-12/+32
"git diff --find-copies-harder" sometimes pretended as if the mode bits have changed for paths that are marked with assume-unchanged bit. * jk/diff-files-assume-unchanged: run_diff_files: do not look at uninitialized stat data
2014-06-25Merge branch 'jk/commit-C-pick-empty' into maintLibravatar Junio C Hamano2-4/+12
"git commit --allow-empty-message -C $commit" did not work when the commit did not have any log message. * jk/commit-C-pick-empty: commit: do not complain of empty messages from -C
2014-06-25Merge branch 'bc/blame-crlf-test' into maintLibravatar Junio C Hamano2-1/+9
"git blame" assigned the blame to the copy in the working-tree if the repository is set to core.autocrlf=input and the file used CRLF line endings. * bc/blame-crlf-test: blame: correctly handle files regardless of autocrlf
2014-06-25Merge branch 'jx/blame-align-relative-time' into maintLibravatar Junio C Hamano1-8/+22
"git blame" miscounted number of columns needed to show localized timestamps, resulting in jaggy left-side-edge of the source code lines in its output. * jx/blame-align-relative-time: blame: dynamic blame_date_width for different locales blame: fix broken time_buf paddings in relative timestamp
2014-06-25Merge branch 'jc/apply-ignore-whitespace' into maintLibravatar Junio C Hamano2-13/+11
"--ignore-space-change" option of "git apply" ignored the spaces at the beginning of line too aggressively, which is inconsistent with the option of the same name "diff" and "git diff" have. * jc/apply-ignore-whitespace: apply --ignore-space-change: lines with and without leading whitespaces do not match
2014-06-25Merge branch 'jk/complete-merge-pull' into maintLibravatar Junio C Hamano1-1/+5
The completion scripts (in contrib/) did not know about quite a few options that are common between "git merge" and "git pull", and a couple of options unique to "git merge". * jk/complete-merge-pull: completion: add missing options for git-merge completion: add a note that merge options are shared
2014-06-25Merge branch 'ow/config-mailmap-pathname' into maintLibravatar Junio C Hamano1-1/+1
The "mailmap.file" configuration option did not support the tilde expansion (i.e. ~user/path and ~/path). * ow/config-mailmap-pathname: config: respect '~' and '~user' in mailmap.file
2014-06-25Merge branch 'as/pretty-truncate' into maintLibravatar Junio C Hamano5-72/+282
The "%<(10,trunc)%s" pretty format specifier in the log family of commands is used to truncate the string to a given length (e.g. 10 in the example) with padding to column-align the output, but did not take into account that number of bytes and number of display columns are different. * as/pretty-truncate: pretty.c: format string with truncate respects logOutputEncoding t4205, t6006: add tests that fail with i18n.logOutputEncoding set t4205 (log-pretty-format): use `tformat` rather than `format` t4041, t4205, t6006, t7102: don't hardcode tested encoding value t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs
2014-06-25Merge branch 'jc/revision-dash-count-parsing' into maintLibravatar Junio C Hamano1-2/+4
"git log -2master" is a common typo that shows two commits starting from whichever random branch that is not 'master' that happens to be checked out currently. * jc/revision-dash-count-parsing: revision: parse "git log -<count>" more carefully
2014-06-25Merge branch 'jk/report-fail-to-read-objects-better' into maintLibravatar Junio C Hamano1-1/+5
Reworded the error message given upon a failure to open an existing loose object file due to e.g. permission issues; it was reported as the object being corrupt, but that is not quite true. * jk/report-fail-to-read-objects-better: open_sha1_file: report "most interesting" errno
2014-06-25Merge branch 'mn/sideband-no-ansi' into maintLibravatar Junio C Hamano1-1/+1
Tools that read diagnostic output in our standard error stream do not want to see terminal control sequence (e.g. erase-to-eol). Detect them by checking if the standard error stream is connected to a tty. * mn/sideband-no-ansi: sideband.c: do not use ANSI control sequence on non-terminal
2014-06-25Merge branch 'je/pager-do-not-recurse' into maintLibravatar Junio C Hamano1-1/+1
We used to unconditionally disable the pager in the pager process we spawn to feed out output, but that prevented people who want to run "less" within "less" from doing so. * je/pager-do-not-recurse: pager: do allow spawning pager recursively
2014-06-12Merge branch 'jc/rev-parse-argh-dashed-multi-words' into maintLibravatar Junio C Hamano2-0/+7
* jc/rev-parse-argh-dashed-multi-words: update-index: fix segfault with missing --cacheinfo argument
2014-06-12pull: do not abuse 'break' inside a shell 'case'Libravatar Jacek Konieczny1-2/+0
It is not C. The code would break under mksh when 'pull.ff' is set: $ git pull /usr/lib/git-core/git-pull[67]: break: can't break Already up-to-date. Signed-off-by: Jacek Konieczny <jajcus@jajcus.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-09revision: parse "git log -<count>" more carefullyLibravatar Junio C Hamano1-2/+4
This mistyped command line simply ignores "master" and ends up showing two commits from the current HEAD: $ git log -2master because we feed "2master" to atoi() without making sure that the whole string is parsed as an integer. Use the strtol_i() helper function instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-04update-index: fix segfault with missing --cacheinfo argumentLibravatar Jeff King2-0/+7
Running "git update-index --cacheinfo" without any further arguments results in a segfault rather than an error message. Commit ec160ae (update-index: teach --cacheinfo a new syntax "mode,sha1,path", 2014-03-23) added code to examine the format of the argument, but forgot to handle the NULL case. Returning an error from the parser is enough, since we then treat it as an old-style "--cacheinfo <mode> <sha1> <path>", and complain that we have less than 3 arguments to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-02mailinfo: use strcmp() for string comparisonLibravatar René Scharfe1-3/+3
The array header is defined as: static const char *header[MAX_HDR_PARSED] = { "From","Subject","Date", }; When looking for the index of a specfic string in that array, simply use strcmp() instead of memcmp(). This avoids running over the end of the string (e.g. with memcmp("Subject", "From", 7)) and gets rid of magic string length constants. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-02sideband.c: do not use ANSI control sequence on non-terminalLibravatar Michael Naumov1-1/+1
Diagnostic messages received on the sideband #2 from the server side are sent to the standard error with ANSI terminal control sequence "\033[K" that erases to the end of line appended at the end of each line. However, some programs (e.g. GitExtensions for Windows) read and interpret and/or show the message without understanding the terminal control sequences, resulting them to be shown to their end users. To help these programs, squelch the control sequence when the standard error stream is not being sent to a tty. NOTE: I considered to cover the case that a pager has already been started. But decided that is probably not worth worrying about here, though, as we shouldn't be using a pager for commands that do network communications (and if we do, omitting the magic line-clearing signal is probably a sane thing to do). Thanks-to: Erik Faye-Lund <kusmabite@gmail.com> Thanks-to: Jeff King <peff@peff.net> Signed-off-by: Michael Naumov <mnaoumov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-30Sync with 1.9.4Libravatar Junio C Hamano2-1/+18
2014-05-30Git 1.9.4Libravatar Junio C Hamano4-3/+20
This is expected to be the final maintenance release for 1.9 series, merging the remaining fixes that are relevant and are already in 2.0. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-30t5537: re-drop http testsLibravatar Jeff King1-28/+0
These were originally removed by 0232852 (t5537: move http tests out to t5539, 2014-02-13). However, they were accidentally re-added in 1ddb4d7 (Merge branch 'nd/upload-pack-shallow', 2014-03-21). This looks like an error in manual conflict resolution. Here's what happened: 1. v1.9.0 shipped with the http tests in t5537. 2. We realized that this caused problems, and built 0232852 on top to move the tests to their own file. This fix made it into v1.9.1. 3. We later had another fix in nd/upload-pack-shallow that also touched t5537. It was built directly on v1.9.0. When we merged nd/upload-pack-shallow to master, we got a conflict; it was built on a version with the http tests, but we had since removed them. The correct resolution was to drop the http tests and keep the new ones, but instead we kept everything. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-28Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname' into maintLibravatar Junio C Hamano2-20/+42
* rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't assume the shell expands the value of PS1
2014-05-28Merge branch 'mw/symlinks' into maintLibravatar Junio C Hamano3-20/+112
* mw/symlinks: setup: fix windows path buffer over-stepping setup: don't dereference in-tree symlinks for absolute paths setup: add abspath_part_inside_repo() function t0060: add tests for prefix_path when path begins with work tree t0060: add test for prefix_path when path == work tree t0060: add test for prefix_path on symlinks via absolute paths t3004: add test for ls-files on symlinks via absolute paths
2014-05-28Git 2.0Libravatar Junio C Hamano2-1/+6
2014-05-27config: respect '~' and '~user' in mailmap.fileLibravatar Øystein Walle1-1/+1
git_config_string() does not handle '~' and '~user' as part of the value. Using git_config_pathname() fixes this. Signed-off-by: Øystein Walle <oystwa@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27gc --auto: do not lock refs in the backgroundLibravatar Nguyễn Thái Ngọc Duy1-6/+20
9f673f9 (gc: config option for running --auto in background - 2014-02-08) puts "gc --auto" in background to reduce user's wait time. Part of the garbage collecting is pack-refs and pruning reflogs. These require locking some refs and may abort other processes trying to lock the same ref. If gc --auto is fired in the middle of a script, gc's holding locks in the background could fail the script, which could never happen before 9f673f9. Keep running pack-refs and "reflog --prune" in foreground to stop parallel ref updates. The remaining background operations (repack, prune and rerere) should not impact running git processes. Reported-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27completion: add missing options for git-mergeLibravatar John Keeping1-1/+4
The options added to __git_merge_options are those that git-pull passes to git-merge, since that variable is used by both commands. Those added directly in _git_merge() are specific to git-merge and are not passed thru from git-pull. Reported-by: Haralan Dobrev <hkdobrev@gmail.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27completion: add a note that merge options are sharedLibravatar John Keeping1-0/+1
This should avoid future confusion after a subsequent patch has added some options to __git_merge_options and some directly in _git_merge(). Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21Update draft release notes to 2.0Libravatar Junio C Hamano1-9/+5
Hopefully for the last time ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21pretty.c: format string with truncate respects logOutputEncodingLibravatar Alexey Shumkin3-8/+13
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given length with an appropriate padding. This works for non-ASCII texts when i18n.logOutputEncoding is UTF-8 only (independently of a printed commit message encoding) but does not work when i18n.logOutputEncoding is NOT UTF-8. In 7e77df3 (pretty: two phase conversion for non utf-8 commits, 2013-04-19) 'format_commit_item' function assumes commit message to be in UTF-8. And that was so until ecaee80 (pretty: --format output should honor logOutputEncoding, 2013-06-26) where conversion to logOutputEncoding was added before calling 'format_commit_message'. Correct this by converting a commit message to UTF-8 first (as it assumed in 7e77df3 (pretty: two phase conversion for non utf-8 commits, 2013-04-19)). Only after that convert a commit message to an actual logOutputEncoding. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21t4205, t6006: add tests that fail with i18n.logOutputEncoding setLibravatar Alexey Shumkin2-2/+213
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given length with an appropriate padding. This works for non-ASCII texts when i18n.logOutputEncoding is UTF-8 only (independently of a printed commit message encoding) but does not work when i18n.logOutputEncoding is NOT UTF-8. There were no breakages as far as were no tests for the case when both a commit message and logOutputEncoding are not UTF-8. Add failing tests for that which will be fixed in the next patch. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21t4205 (log-pretty-format): use `tformat` rather than `format`Libravatar Alexey Shumkin1-39/+13
Use `tformat` to avoid using of `echo` to complete end of line. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21t4041, t4205, t6006, t7102: don't hardcode tested encoding valueLibravatar Alexey Shumkin4-27/+39
The tested encoding is always available in a variable. Use it instead of hardcoding. Also, to be in line with other tests use ISO8859-1 (uppercase) rather then iso8859-1. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-20Git 2.0-rc4Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-20RelNotes/2.0.0.txt: Fix several grammar issues, notably a lack of hyphens, ↵Libravatar Jason St. John1-36/+37
double quotes, or articles Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-20Revert "Merge branch 'jc/graduate-remote-hg-bzr' (early part)"Libravatar Junio C Hamano11-4360/+87
Instead of showing a warning and working as before, fail and show the message and force immediate upgrade from their upstream repositories when these tools are run, per request from their primary author. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-20move "--follow needs one pathspec" rule to diff_setup_doneLibravatar Jeff King2-6/+5
Because of the way "--follow" is implemented, we must have exactly one pathspec. "git log" enforces this restriction, but other users of the revision traversal code do not. For example, "git format-patch --follow" will segfault during try_to_follow_renames, as we have no pathspecs at all. We can push this check down into diff_setup_done, which is probably a better place anyway. It is the diff code that introduces this restriction, so other parts of the code should not need to care themselves. Reported-by: "Michael S. Tsirkin" <mst@redhat.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19Merge branch 'jc/graduate-remote-hg-bzr' (early part)Libravatar Junio C Hamano6-71/+62
* 'jc/graduate-remote-hg-bzr' (early part): remote-helpers: point at their upstream repositories contrib: remote-helpers: add move warnings (v2.0) Revert "Merge branch 'fc/transport-helper-sync-error-fix'"
2014-05-19remote-helpers: point at their upstream repositoriesLibravatar Junio C Hamano1-0/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19contrib: remote-helpers: add move warnings (v2.0)Libravatar Felipe Contreras2-0/+6
The tools are now maintained out-of-tree, and they have a regression in v2.0. It's better to start warning the users as soon as possible. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19Revert "Merge branch 'fc/transport-helper-sync-error-fix'"Libravatar Junio C Hamano3-71/+37
This reverts commit d508e4a8e2391ae2596403b6478d01cf3d5f928f, reversing changes made to e42552135a2a396f37053a89f44952ea907870b2. The author of the original topic says he broke the upcoming 2.0 release with something that relates to "synchronization crash regression" while refusing to give further specifics, so this would unfortunately be the safest option for the upcoming release. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname'Libravatar Junio C Hamano2-20/+42
* rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't assume the shell expands the value of PS1
2014-05-19git-prompt.sh: don't assume the shell expands the value of PS1Libravatar Richard Hansen2-20/+42
Not all shells subject the prompt string to parameter expansion. Test whether the shell will expand the value of PS1, and use the result to control whether raw ref names are included directly in PS1. This fixes a regression introduced in commit 8976500 ("git-prompt.sh: don't put unsanitized branch names in $PS1"): zsh does not expand PS1 by default, but that commit assumed it did. The bug resulted in prompts containing the literal string '${__git_ps1_branch_name}' instead of the actual branch name. Reported-by: Caleb Thompson <caleb@calebthompson.io> Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsLibravatar Alexey Shumkin1-3/+11
The expected SHA-1 digests are always available in variables. Use them instead of hardcoding. That was introduced in a742f2a (t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs, 2013-06-26) but unfortunately was not followed in 5e1361c (log: properly handle decorations with chained tags, 2013-12-17) Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>