summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-05-09Git 1.9.3Libravatar Junio C Hamano2-2/+3
The third maintenance release for Git 1.9; contains all the fixes that are scheduled to appear in Git 2.0 since 1.9.2. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-08shell doc: remove stray "+" in exampleLibravatar Jonathan Nieder1-1/+1
The git-shell(1) manpage says EXAMPLE To disable interactive logins, displaying a greeting instead: + $ chsh -s /usr/bin/git-shell $ mkdir $HOME/git-shell-commands [...] The stray "+" has been there ever since the example was added in v1.8.3-rc0~210^2 (shell: new no-interactive-login command to print a custom message, 2013-03-09). The "+" sign between paragraphs is needed in asciidoc to attach extra paragraphs to a list item but here it is not needed and ends up rendered as a literal "+". Remove it. A quick search with "grep -e '<p>+' /usr/share/doc/git/html/*.html" doesn't find any other instances of this problem. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-08Start preparing for 1.9.3Libravatar Junio C Hamano2-1/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-08Merge branch 'cl/p4-use-diff-tree' into maintLibravatar Junio C Hamano1-1/+1
"git p4" dealing with changes in binary files were broken by a change in 1.9 release. * cl/p4-use-diff-tree: git-p4: format-patch to diff-tree change breaks binary patches
2014-05-08Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname' into maintLibravatar Junio C Hamano2-24/+54
The shell prompt script (in contrib/), when using the PROMPT_COMMAND interface, used an unsafe construct when showing the branch name in $PS1. * rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't put unsanitized branch names in $PS1
2014-05-08Merge branch 'km/avoid-non-function-return-in-rebase' into maintLibravatar Junio C Hamano4-10/+46
"git rebase" used a POSIX shell construct FreeBSD /bin/sh does not work well with. * km/avoid-non-function-return-in-rebase: Revert "rebase: fix run_specific_rebase's use of "return" on FreeBSD" rebase: avoid non-function use of "return" on FreeBSD
2014-05-08Merge branch 'tb/unicode-6.3-zero-width' into maintLibravatar Junio C Hamano1-5/+4
Some more Unicode codepoints defined in Unicode 6.3 as having zero width have been taught to our display column counting logic. * tb/unicode-6.3-zero-width: utf8.c: partially update to version 6.3
2014-05-08Merge branch 'km/avoid-bs-in-shell-glob' into maintLibravatar Junio C Hamano1-2/+2
Some tests used shell constructs that did not work well on FreeBSD * km/avoid-bs-in-shell-glob: test: fix t5560 on FreeBSD
2014-05-08Merge branch 'km/avoid-cp-a' into maintLibravatar Junio C Hamano1-2/+2
Some tests used shell constructs that did not work well on FreeBSD * km/avoid-cp-a: test: fix t7001 cp to use POSIX options
2014-05-07git-p4: format-patch to diff-tree change breaks binary patchesLibravatar Tolga Ceylan1-1/+1
When applying binary patches a full index is required. format-patch already handles this, but diff-tree needs '--full-index' argument to always output full index. When git-p4 runs git-apply to test the patch, git-apply rejects the patch due to abbreviated blob object names. This is the error message git-apply emits in this case: error: cannot apply binary patch to '<filename>' without full index line error: <filename>: patch does not apply Signed-off-by: Tolga Ceylan <tolga.ceylan@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-22git-prompt.sh: don't put unsanitized branch names in $PS1Libravatar Richard Hansen2-24/+54
Both bash and zsh subject the value of PS1 to parameter expansion, command substitution, and arithmetic expansion. Rather than include the raw, unescaped branch name in PS1 when running in two- or three-argument mode, construct PS1 to reference a variable that holds the branch name. Because the shells do not recursively expand, this avoids arbitrary code execution by specially-crafted branch names such as '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)'. Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-17Revert "rebase: fix run_specific_rebase's use of "return" on FreeBSD"Libravatar Kyle J. McKay1-10/+1
This reverts commit 99855ddf4bd319cd06a0524e755ab1c1b7d39f3b. The workaround 99855ddf introduced to deal with problematic "return" statements in scripts run by "dot" commands located inside functions only handles one part of the problem. The issue has now been addressed by not using "return" statements in this way in the git-rebase--*.sh scripts. This workaround is therefore no longer necessary, so clean up the code by reverting it. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-17rebase: avoid non-function use of "return" on FreeBSDLibravatar Kyle J. McKay3-0/+45
Since a1549e10, 15d4bf2e and 01a1e646 (first appearing in v1.8.4) the git-rebase--*.sh scripts have used a "return" to stop execution of the dot-sourced file and return to the "dot" command that dot-sourced it. The /bin/sh utility on FreeBSD however behaves poorly under some circumstances when such a "return" is executed. In particular, if the "dot" command is contained within a function, then when a "return" is executed by the script it runs (that is not itself inside a function), control will return from the function that contains the "dot" command skipping any statements that might follow the dot command inside that function. Commit 99855ddf (first appearing in v1.8.4.1) addresses this by making the "dot" command the last line in the function. Unfortunately the FreeBSD /bin/sh may also execute some statements in the script run by the "dot" command that appear after the troublesome "return". The fix in 99855ddf does not address this problem. For example, if you have script1.sh with these contents: run_script2() { . "$(dirname -- "$0")/script2.sh" _e=$? echo only this line should show [ $_e -eq 5 ] || echo expected status 5 got $_e return 3 } run_script2 e=$? [ $e -eq 3 ] || { echo expected status 3 got $e; exit 1; } And script2.sh with these contents: if [ 5 -gt 3 ]; then return 5 fi case bad in *) echo always shows esac echo should not get here ! : When running script1.sh (e.g. '/bin/sh script1.sh' or './script1.sh' after making it executable), the expected output from a POSIX shell is simply the single line: only this line should show However, when run using FreeBSD's /bin/sh, the following output appears instead: should not get here expected status 3 got 1 Not only did the lines following the "dot" command in the run_script2 function in script1.sh get skipped, but additional lines in script2.sh following the "return" got executed -- but not all of them (e.g. the "echo always shows" line did not run). These issues can be avoided by not using a top-level "return" in script2.sh. If script2.sh is changed to this: main() { if [ 5 -gt 3 ]; then return 5 fi case bad in *) echo always shows esac echo should not get here ! : } main Then it behaves the same when using FreeBSD's /bin/sh as when using other more POSIX compliant /bin/sh implementations. We fix the git-rebase--*.sh scripts in a similar fashion by moving the top-level code that contains "return" statements into its own function and then calling that as the last line in the script. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-11test: fix t5560 on FreeBSDLibravatar Kyle J. McKay1-2/+2
Since fd0a8c2e (first appearing in v1.7.0), the t/t5560-http-backend-noserver.sh test has used a backslash escape inside a ${} expansion in order to specify a literal '?' character. Unfortunately the FreeBSD /bin/sh does not interpret this correctly. In a POSIX compliant shell, the following: x='one?two?three' echo "${x#*\?}" Would be expected to produce this: two?three When using the FreeBSD /bin/sh instead you get this: one?two?three In fact the FreeBSD /bin/sh treats the backslash as a literal character to match so that this: y='one\two\three' echo "${y#*\?}" Produces this unexpected value: wo\three In this case the backslash is not only treated literally, it also fails to defeat the special meaning of the '?' character. Instead, we can use the [...] construct to defeat the special meaning of the '?' character and match it exactly in a way that works for the FreeBSD /bin/sh as well as other POSIX /bin/sh implementations. Changing the example like so: x='one?two?three' echo "${x#*[?]}" Produces the expected output using the FreeBSD /bin/sh. Therefore, change the use of \? to [?] in order to be compatible with the FreeBSD /bin/sh which allows t/t5560-http-backend-noserver.sh to pass on FreeBSD again. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-11test: fix t7001 cp to use POSIX optionsLibravatar Kyle J. McKay1-2/+2
Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the t7001-mv test has used "cp -a" to perform a copy in several of the tests. However, the "-a" option is not required for a POSIX cp utility and some platforms' cp utilities do not support it. The POSIX equivalent of -a is -R -P -p. Change "cp -a" to "cp -R -P -p" so that the t7001-mv test works on systems with a cp utility that only implements the POSIX required set of options and not the "-a" option. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-09Git 1.9.2Libravatar Junio C Hamano3-2/+23
The second maintenance release for Git 1.9; contains all the fixes that are scheduled to appear in Git 2.0. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-09Merge branch 'jl/nor-or-nand-and' into maintLibravatar Junio C Hamano57-90/+88
* jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
2014-04-09Merge branch 'cn/fetch-prune-overlapping-destination' into maintLibravatar Junio C Hamano2-6/+64
* cn/fetch-prune-overlapping-destination: fetch: handle overlaping refspecs on --prune fetch: add a failing test for prunning with overlapping refspecs
2014-04-09Merge branch 'mh/update-ref-batch-create-fix' into maintLibravatar Junio C Hamano2-0/+12
* mh/update-ref-batch-create-fix: update-ref: fail create operation over stdin if ref already exists
2014-04-09Merge branch 'jk/commit-dates-parsing-fix' into maintLibravatar Junio C Hamano5-4/+47
* jk/commit-dates-parsing-fix: t4212: loosen far-in-future test for AIX date: recognize bogus FreeBSD gmtime output
2014-04-09Merge branch 'jc/fix-diff-no-index-diff-opt-parse' into maintLibravatar Junio C Hamano1-1/+1
* jc/fix-diff-no-index-diff-opt-parse: diff-no-index: correctly diagnose error return from diff_opt_parse()
2014-04-09Merge commit 'doc/http-backend: missing accent grave in literal mark-up'Libravatar Junio C Hamano1-1/+1
* commit '5df05146d5cb94628a3dfc53063c802ee1152cec': doc/http-backend: missing accent grave in literal mark-up
2014-04-09doc/http-backend: missing accent grave in literal mark-upLibravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-09utf8.c: partially update to version 6.3Libravatar Torsten Bögershausen1-5/+4
Unicode 6.3 defines more code points as combining or accents. For example, the character "ö" could be expressed as an "o" followed by U+0308 COMBINING DIARESIS (aka umlaut, double-dot-above). We should consider that such a sequence of two codepoints occupies one display column for the alignment purposes, and for that, git_wcwidth() should return 0 for them. Affected codepoints are: U+0358..U+035C U+0487 U+05A2, U+05BA, U+05C5, U+05C7 U+0604, U+0616..U+061A, U+0659..U+065F Earlier unicode standards had defined these as "reserved". Only the range 0..U+07FF has been checked to see which codepoints need to be marked as 0-width while preparing for this commit; more updates may be needed. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-08Update draft release notes to 1.9.2Libravatar Junio C Hamano1-0/+9
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-08Merge branch 'mm/status-porcelain-format-i18n-fix' into maintLibravatar Junio C Hamano2-5/+9
* mm/status-porcelain-format-i18n-fix: status: disable translation when --porcelain is used
2014-04-08Merge branch 'bp/commit-p-editor' into maintLibravatar Junio C Hamano10-39/+137
* bp/commit-p-editor: run-command: mark run_hook_with_custom_index as deprecated merge hook tests: fix and update tests merge: fix GIT_EDITOR override for commit hook commit: fix patch hunk editing with "commit -p -m" test patch hunk editing with "commit -p -m" merge hook tests: use 'test_must_fail' instead of '!' merge hook tests: fix missing '&&' in test
2014-04-03Start preparing for 1.9.1Libravatar Junio C Hamano2-1/+39
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-03Merge branch 'jk/mv-submodules-fix' into maintLibravatar Junio C Hamano2-1/+21
* jk/mv-submodules-fix: mv: prevent mismatched data when ignoring errors. builtin/mv: fix out of bounds write Conflicts: t/t7001-mv.sh
2014-04-03Merge branch 'mh/remove-subtree-long-pathname-fix' into maintLibravatar Junio C Hamano1-32/+32
* mh/remove-subtree-long-pathname-fix: entry.c: fix possible buffer overflow in remove_subtree() checkout_entry(): use the strbuf throughout the function
2014-04-03Merge branch 'jk/lib-terminal-lazy' into maintLibravatar Junio C Hamano1-18/+19
* jk/lib-terminal-lazy: t/lib-terminal: make TTY a lazy prerequisite
2014-04-03Merge branch 'nd/index-pack-error-message' into maintLibravatar Junio C Hamano1-2/+2
* nd/index-pack-error-message: index-pack: report error using the correct variable
2014-04-03Merge branch 'us/printf-not-echo' into maintLibravatar Junio C Hamano2-3/+3
* us/printf-not-echo: test-lib.sh: do not "echo" caller-supplied strings rebase -i: do not "echo" random user-supplied strings
2014-04-03Merge branch 'rr/doc-merge-strategies' into maintLibravatar Junio C Hamano1-2/+2
* rr/doc-merge-strategies: Documentation/merge-strategies: avoid hyphenated commands
2014-04-03Merge branch 'jk/shallow-update-fix' into maintLibravatar Junio C Hamano5-56/+49
* jk/shallow-update-fix: shallow: verify shallow file after taking lock shallow: automatically clean up shallow tempfiles shallow: use stat_validity to check for up-to-date file
2014-04-03Merge branch 'jc/stash-pop-not-popped' into maintLibravatar Junio C Hamano1-2/+8
* jc/stash-pop-not-popped: stash pop: mention we did not drop the stash upon failing to apply
2014-04-03Merge branch 'jn/wt-status' into maintLibravatar Junio C Hamano3-55/+88
* jn/wt-status: wt-status: lift the artificual "at least 20 columns" floor wt-status: i18n of section labels wt-status: extract the code to compute width for labels wt-status: make full label string to be subject to l10n
2014-04-02update-ref: fail create operation over stdin if ref already existsLibravatar Aman Gupta2-0/+12
Signed-off-by: Aman Gupta <aman@tmm1.net> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Acked-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-01t4212: loosen far-in-future test for AIXLibravatar Jeff King1-4/+2
One of the tests in t4212 checks our behavior when we feed gmtime a date so far in the future that it gives up and returns NULL. Some implementations, like AIX, may actually just provide us a bogus result instead. It's not worth it for us to come up with heuristics that guess whether the return value is sensible or not. On good platforms where gmtime reports the problem to us with NULL, we will print the epoch value. On bad platforms, we will print garbage. But our test should be written for the lowest common denominator so that it passes everywhere. Reported-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-01date: recognize bogus FreeBSD gmtime outputLibravatar Jeff King4-0/+45
Most gmtime implementations return a NULL value when they encounter an error (and this behavior is specified by ANSI C and POSIX). FreeBSD's implementation, however, will simply leave the "struct tm" untouched. Let's also recognize this and convert it to a NULL (with this patch, t4212 should pass on FreeBSD). Reported-by: René Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31code and test: fix misuses of "nor"Libravatar Justin Lebar12-16/+16
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31comments: fix misuses of "nor"Libravatar Justin Lebar20-27/+26
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31contrib: fix misuses of "nor"Libravatar Justin Lebar2-3/+3
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Documentation: fix misuses of "nor"Libravatar Justin Lebar25-44/+43
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31diff-no-index: correctly diagnose error return from diff_opt_parse()Libravatar Junio C Hamano1-1/+1
diff_opt_parse() returns the number of options parsed, or often returns error() which is defined to return -1. Yes, return value of 0 is "I did not process that option at all", which should cause the caller to say that, but negative return should not be forgotten. This bug caused "diff --no-index" to infinitely show the same error message because the returned value was used to decrement the loop control variable, e.g. $ git diff --no-index --color=words a b error: option `color' expects "always", "auto", or "never" error: option `color' expects "always", "auto", or "never" ... Instead, make it act like so: $ git diff --no-index --color=words a b error: option `color' expects "always", "auto", or "never" fatal: invalid diff option/value: --color=words Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-26fetch: handle overlaping refspecs on --pruneLibravatar Carlos Martín Nieto2-7/+45
We need to consider that a remote-tracking branch may match more than one rhs of a fetch refspec. In such a case, it is not enough to stop at the first match but look at all of the matches in order to determine whether a head is stale. To this goal, introduce a variant of query_refspecs which returns all of the matching refspecs and loop over those answers to check for staleness. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-26status: disable translation when --porcelain is usedLibravatar Matthieu Moy2-5/+9
"git status --branch --porcelain" displays the status of the branch (ahead, behind, gone), and used gettext to translate the string. Use hardcoded strings when --porcelain is used, but keep the gettext translation for "git status --short" which is essentially the same, but meant to be read by a human. Reported-by: Anarky <ghostanarky@gmail.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18Git 1.9.1Libravatar Junio C Hamano4-3/+63
The version numbering scheme has changed since Git 1.9 and we dropped the third dewey-decimal from the traditional numbering (e.g. both 1.8.4 and 1.8.5 were major feature releases). This release 1.9.1 is the first maintenance relase for Git 1.9. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18Merge branch 'jk/clean-d-pathspec' into maintLibravatar Junio C Hamano2-11/+25
"git clean -d pathspec" did not use the given pathspec correctly and ended up cleaning too much. * jk/clean-d-pathspec: clean: simplify dir/not-dir logic clean: respect pathspecs with "-d"
2014-03-18Merge branch 'da/difftool-git-files' into maintLibravatar Junio C Hamano2-16/+16
"git difftool" misbehaved when the repository is bound to the working tree with the ".git file" mechanism, where a textual file ".git" tells us where it is. * da/difftool-git-files: t7800: add a difftool test for .git-files difftool: support repositories with .git-files