summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2012-11-09Merge branch 'ph/maint-submodule-status-fix'Libravatar Jeff King1-2/+2
Cleans up some leftover bits from an earlier submodule change. * ph/maint-submodule-status-fix: submodule status: remove unused orig_* variables t7407: Fix recursive submodule test
2012-11-09Merge branch 'fc/completion-send-email-with-format-patch'Libravatar Jeff King1-0/+5
* fc/completion-send-email-with-format-patch: completion: add format-patch options to send-email
2012-11-09Merge branch 'mo/cvs-server-cleanup'Libravatar Jeff King2-1/+106
Cleanups to prepare for mo/cvs-server-updates. * mo/cvs-server-cleanup: Use character class for sed expression instead of \s cvsserver status: provide real sticky info cvsserver: cvs add: do not expand directory arguments cvsserver: use whole CVS rev number in-process; don't strip "1." prefix cvsserver: split up long lines in req_{status,diff,log} cvsserver: clean up client request handler map comments cvsserver: remove unused functions _headrev and gethistory cvsserver update: comment about how we shouldn't remove a user-modified file cvsserver: add comments about database schema/usage cvsserver: removed unused sha1Or-k mode from kopts_from_path cvsserver t9400: add basic 'cvs log' test
2012-11-09Merge branch 'km/send-email-compose-encoding'Libravatar Jeff King1-0/+86
"git send-email --compose" can let the user create a non-ascii cover letter message, but there was not a way to mark it with appropriate content type before sending it out. Further updates fix subject quoting. * km/send-email-compose-encoding: git-send-email: add rfc2047 quoting for "=?" git-send-email: introduce quote_subject() git-send-email: skip RFC2047 quoting for ASCII subjects git-send-email: use compose-encoding for Subject git-send-email: introduce compose-encoding
2012-11-09Merge branch 'js/format-2047'Libravatar Jeff King2-87/+148
Fixes many rfc2047 quoting issues in the output from format-patch. * js/format-2047: format-patch tests: check quoting/encoding in To: and Cc: headers format-patch: fix rfc2047 address encoding with respect to rfc822 specials format-patch: make rfc2047 encoding more strict format-patch: introduce helper function last_line_length() format-patch: do not wrap rfc2047 encoded headers too late format-patch: do not wrap non-rfc2047 headers too early utf8: fix off-by-one wrapping of text
2012-11-09Merge branch 'nd/attr-match-optim-more'Libravatar Jeff King2-0/+16
Start laying the foundation to build the "wildmatch" after we can agree on its desired semantics. * nd/attr-match-optim-more: attr: more matching optimizations from .gitignore gitignore: make pattern parsing code a separate function exclude: split pathname matching code into a separate function exclude: fix a bug in prefix compare optimization exclude: split basename matching code into a separate function exclude: stricten a length check in EXC_FLAG_ENDSWITH case
2012-11-04Merge branch 'tb/maint-t9200-case-insensitive'Libravatar Jeff King1-1/+1
* tb/maint-t9200-case-insensitive: Fix t9200 on case insensitive file systems
2012-10-29Merge branch 'rs/branch-del-symref'Libravatar Jeff King1-0/+19
A symbolic ref refs/heads/SYM was not correctly removed with "git branch -d SYM"; the command removed the ref pointed by SYM instead. * rs/branch-del-symref: branch: show targets of deleted symrefs, not sha1s branch: skip commit checks when deleting symref branches branch: delete symref branch, not its target branch: factor out delete_branch_config() branch: factor out check_branch_commit()
2012-10-29Merge branch 'jk/sh-setup-in-filter-branch'Libravatar Jeff King1-2/+3
Refactoring to avoid code duplication in shell scripts. * jk/sh-setup-in-filter-branch: filter-branch: use git-sh-setup's ident parsing functions git-sh-setup: refactor ident-parsing functions
2012-10-29Merge branch 'nd/grep-true-path'Libravatar Jeff King1-0/+22
"git grep -e pattern <tree>" asked the attribute system to read "<tree>:.gitattributes" file in the working tree, which was nonsense. * nd/grep-true-path: grep: stop looking at random places for .gitattributes
2012-10-29Merge branch 'jc/grep-pcre-loose-ends'Libravatar Jeff King1-0/+6
"git log -F -E --grep='<ere>'" failed to use the given <ere> pattern as extended regular expression, and instead looked for the string literally. The early part of this series is a fix for it; the latter part teaches log to respect the grep.* configuration. * jc/grep-pcre-loose-ends: log: honor grep.* configuration log --grep: accept --basic-regexp and --perl-regexp log --grep: use the same helper to set -E/-F options as "git grep" revisions: initialize revs->grep_filter using grep_init() grep: move pattern-type bits support to top-level grep.[ch] grep: move the configuration parsing logic to grep.[ch] builtin/grep.c: make configuration callback more reusable
2012-10-29Merge branch 'jl/submodule-add-by-name'Libravatar Jeff King2-1/+76
If you remove a submodule, in order to keep the repository so that "git checkout" to an older commit in the superproject history can resurrect the submodule, the real repository will stay in $GIT_DIR of the superproject. A later "git submodule add $path" to add a different submodule at the same path will fail. Diagnose this case a bit better, and if the user really wants to add an unrelated submodule at the same path, give the "--name" option to give it a place in $GIT_DIR of the superproject that does not conflict with the original submodule. * jl/submodule-add-by-name: submodule add: Fail when .git/modules/<name> already exists unless forced Teach "git submodule add" the --name option
2012-10-29Merge branch 'jl/submodule-rm'Libravatar Jeff King1-0/+343
"git rm submodule" cannot blindly remove a submodule directory as its working tree may have local changes, and worse yet, it may even have its repository embedded in it. Teach it some special cases where it is safe to remove a submodule, specifically, when there is no local changes in the submodule working tree, and its repository is not embedded in its working tree but is elsewhere and uses the gitfile mechanism to point at it. * jl/submodule-rm: submodule: teach rm to remove submodules unless they contain a git directory
2012-10-29t7407: Fix recursive submodule testLibravatar Phil Hord1-2/+2
A test in t7404-submodule-foreach purports to test that the --cached flag is properly noticed by --recursive calls to the foreach command as it descends into nested submodules. However, the test really does not perform this test since the change it looks for is in a top-level submodule handled by the first invocation of the command. To properly test for the flag being passed to recursive invocations, the change must be buried deeper in the hierarchy. Move the change one level deeper so it properly verifies the recursive machinery of the 'git submodule status' command. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Jeff King <peff@peff.net>
2012-10-28Fix t9200 on case insensitive file systemsLibravatar Torsten Bögershausen1-1/+1
t9200 defines $CVSROOT where cvs should init its repository $CVSROOT is set to $PWD/cvsroot. cvs init is supposed to create the repository inside $PWD/cvsroot/CVSROOT "cvs init" (e.g. version 1.11.23) checks if the last element of the path is "CVSROOT", and if a directory with e.g. $PWD/cvsroot/CVSROOT already exists. For such a $CVSROOT cvs refuses to init a repository here: "Cannot initialize repository under existing CVSROOT: On a case insenstive file system cvsroot and CVSROOT are the same directories and t9200 fails. Solution: use $PWD/tmpcvsroot instead of cvsroot $PWD/cvsroot Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Jeff King <peff@peff.net>
2012-10-26Use character class for sed expression instead of \sLibravatar Ben Walton1-1/+1
Sed on Mac OS X doesn't handle \s in a sed expressions so use a more portable character set expression instead. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25Merge branch 'jc/test-say-color-avoid-echo-escape'Libravatar Jeff King1-1/+1
Recent nd/wildmatch series was the first to reveal this ancient bug in the test scaffolding. * jc/test-say-color-avoid-echo-escape: test-lib: Fix say_color () not to interpret \a\b\c in the message
2012-10-25Merge branch 'fa/remote-svn'Libravatar Jeff King1-0/+84
A GSoC project. * fa/remote-svn: Add a test script for remote-svn remote-svn: add marks-file regeneration Add a svnrdump-simulator replaying a dump file for testing remote-svn: add incremental import remote-svn: Activate import/export-marks for fast-import Create a note for every imported commit containing svn metadata vcs-svn: add fast_export_note to create notes Allow reading svn dumps from files via file:// urls remote-svn, vcs-svn: Enable fetching to private refs When debug==1, start fast-import with "--stats" instead of "--quiet" Add documentation for the 'bidi-import' capability of remote-helpers Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability Add argv_array_detach and argv_array_free_detached Add svndump_init_fd to allow reading dumps from arbitrary FDs Add git-remote-testsvn to Makefile Implement a remote helper for svn in C
2012-10-25Merge branch 'jm/diff-context-config'Libravatar Jeff King1-0/+92
Teaches a new configuration variable to "git diff" Porcelain and its friends. * jm/diff-context-config: t4055: avoid use of sed 'a' command diff: diff.context configuration gives default to -U
2012-10-25git-send-email: skip RFC2047 quoting for ASCII subjectsLibravatar Krzysztof Mazur1-0/+17
The git-send-email always use RFC2047 subject quoting for files with "broken" encoding - non-ASCII files without Content-Transfer-Encoding, even for ASCII subjects. This is harmless but unnecessarily ugly for people reading the raw headers. This patch skips rfc2047 quoting when the subject does not need it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: use compose-encoding for SubjectLibravatar Krzysztof Mazur1-0/+14
The commit "git-send-email: introduce compose-encoding" introduced the compose-encoding option to specify the introduction email encoding (--compose option), but the email Subject encoding was still hardcoded to UTF-8. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-18filter-branch: use git-sh-setup's ident parsing functionsLibravatar Jeff King1-2/+3
This saves us some code, but it also reduces the number of processes we start for each filtered commit. Since we can parse both author and committer in the same sed invocation, we save one process. And since the new interface avoids tr, we save 4 processes. It also avoids using "tr", which has had some odd portability problems reported with from Solaris's xpg6 version. We also tweak one of the tests in t7003 to double-check that we are properly exporting the variables (because test-lib.sh exports GIT_AUTHOR_NAME, it will be automatically exported in subprograms. We override this to make sure that filter-branch handles it properly itself). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: show targets of deleted symrefs, not sha1sLibravatar René Scharfe1-3/+2
git branch reports the abbreviated hash of the head commit of a deleted branch to make it easier for a user to undo the operation. For symref branches this doesn't help. Print the symref target instead for them. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: skip commit checks when deleting symref branchesLibravatar René Scharfe1-0/+9
Before a branch is deleted, we check that it points to a valid commit. With -d we also check that the commit is a merged; this check is not done with -D. The reason for that is that commits pointed to by branches should never go missing; if they do then something broke and it's better to stop instead of adding to the mess. And a non-merged commit may contain changes that are worth preserving, so we require the stronger option -D instead of -d to get rid of them. If a branch consists of a symref, these concerns don't apply. Deleting such a branch can't make a commit become unreferenced, so we don't need to check if it is merged, or even if it is actually a valid commit. Skip them in that case. This allows us to delete dangling symref branches. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: delete symref branch, not its targetLibravatar René Scharfe1-0/+11
If a branch that is to be deleted happens to be a symref to another branch, the current code removes the targeted branch instead of the one it was called for. Change this surprising behaviour and delete the symref branch instead. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch tests: check quoting/encoding in To: and Cc: headersLibravatar Jan H. Schönherr1-32/+66
git-format-patch does currently not parse user supplied extra header values (e. g., --cc, --add-header) and just replays them. That forces users to add them RFC 2822/2047 conform in encoded form, e.g. --cc '=?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <...>' which is inconvenient. We would want to update git-format-patch to accept human-readable input --cc 'Jan H. Schönherr <...>' and handle the encoding, wrapping and quoting internally in the future, similar to what is already done in git-send-email. The necessary code should mostly exist in the code paths that handle the From: and Subject: headers. Whether we want to do this only for the git-format-patch options --to and --cc (and the corresponding config options) or also for user supplied headers via --add-header, is open for discussion. For now, add test_expect_failure tests for To: and Cc: headers as a reminder and fix tests that would otherwise fail should this get implemented. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: fix rfc2047 address encoding with respect to rfc822 specialsLibravatar Jan H. Schönherr1-1/+1
According to RFC 2047 and RFC 822, rfc2047 encoded words and and rfc822 quoted strings do not mix. Since add_rfc2047() no longer leaves RFC 822 specials behind, the quoting is also no longer necessary to create a standard-conforming mail. Remove the quoting, when RFC 2047 encoding takes place. This actually requires to refactor add_rfc2047() a bit, so that the different cases can be distinguished. With this patch, my own name gets correctly decoded as Jan H. Schönherr (without quotes) and not as "Jan H. Schönherr" (with quotes). Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: make rfc2047 encoding more strictLibravatar Jan H. Schönherr1-4/+11
RFC 2047 requires more characters to be encoded than it is currently done. Especially, RFC 2047 distinguishes between allowed remaining characters in encoded words in addresses (From, To, etc.) and other headers, such as Subject. Make add_rfc2047() and is_rfc2047_special() location dependent and include all non-allowed characters to hopefully be RFC 2047 conformant. This especially fixes a problem, where RFC 822 specials (e. g. ".") were left unencoded in addresses, which was solved with a non-standard-conforming workaround in the past (which is going to be removed in a follow-up patch). Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: do not wrap rfc2047 encoded headers too lateLibravatar Jan H. Schönherr1-23/+35
Encoded characters add more than one character at once to an encoded header. Include all characters that are about to be added in the length calculation for wrapping. Additionally, RFC 2047 imposes a maximum line length of 76 characters if that line contains an rfc2047 encoded word. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: do not wrap non-rfc2047 headers too earlyLibravatar Jan H. Schönherr1-26/+34
Do not wrap the second and later lines of non-rfc2047-encoded headers substantially before the 78 character limit. Instead of passing the remaining length of the first line as wrapping width, use the correct maximum length and tell strbuf_add_wrapped_bytes() how many characters of the first line are already used. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18utf8: fix off-by-one wrapping of textLibravatar Jan H. Schönherr1-2/+2
The wrapping logic in strbuf_add_wrapped_text() does currently not allow lines that entirely fill the allowed width, instead it wraps the line one character too early. For example, the text "This is the sixth commit." formatted via "%w(11,1,2)" (wrap at 11 characters, 1 char indent of first line, 2 char indent of following lines) results in four lines: " This is", " the", " sixth", " commit." This is wrong, because " the sixth" is exactly 11 characters long, and thus allowed. Fix this by allowing the (width+1) character of a line to be a valid wrapping point if it is a whitespace character. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-17Merge branch 'bw/cp-a-is-gnuism' into maintLibravatar Junio C Hamano3-3/+3
* bw/cp-a-is-gnuism: tests: "cp -a" is a GNUism
2012-10-17Merge branch 'jc/maint-t1450-fsck-order-fix' into maintLibravatar Junio C Hamano1-3/+1
* jc/maint-t1450-fsck-order-fix: t1450: the order the objects are checked is undefined
2012-10-17Merge branch 'rr/test-use-shell-path-not-shell' into maintLibravatar Junio C Hamano1-16/+16
* rr/test-use-shell-path-not-shell: test-lib: use $SHELL_PATH, not $SHELL
2012-10-17Merge branch 'rr/test-make-sure-we-have-git' into maintLibravatar Junio C Hamano2-10/+9
* rr/test-make-sure-we-have-git: t/test-lib: make sure Git has already been built
2012-10-17Merge branch 'jc/ll-merge-binary-ours' into maintLibravatar Junio C Hamano1-1/+13
* jc/ll-merge-binary-ours: ll-merge: warn about inability to merge binary files only when we can't attr: "binary" attribute should choose built-in "binary" merge driver merge: teach -Xours/-Xtheirs to binary ll-merge driver
2012-10-16cvsserver status: provide real sticky infoLibravatar Matthew Ogilvie1-0/+35
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-16cvsserver: use whole CVS rev number in-process; don't strip "1." prefixLibravatar Matthew Ogilvie1-1/+1
Keep track of the whole CVS revision number in-process. This will clarify code when we start handling non-linear revision numbers later. There is one externally visible change: conflict markers after an update will now include the full CVS revision number, including the "1." prefix. It used to leave off the prefix. Other than the conflict marker, this change doesn't effect external functionality. No new features, and the DB schema is unchanged such that it continues to store just the stripped rev numbers (without prefix). Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-16cvsserver t9400: add basic 'cvs log' testLibravatar Matthew Ogilvie1-0/+70
'cvs log' output is arguably deficient in a number of ways (see the comment added with the test), but add a test for the current output to detect for accidental regressions. Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-16completion: add format-patch options to send-emailLibravatar Felipe Contreras1-0/+5
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-15attr: more matching optimizations from .gitignoreLibravatar Nguyễn Thái Ngọc Duy1-0/+10
.gitattributes and .gitignore share the same pattern syntax but has separate matching implementation. Over the years, ignore's implementation accumulates more optimizations while attr's stays the same. This patch reuses the core matching functions that are also used by excluded_from_list. excluded_from_list and path_matches can't be merged due to differences in exclude and attr, for example: * "!pattern" syntax is forbidden in .gitattributes. As an attribute can be unset (i.e. set to a special value "false") or made back to unspecified (i.e. not even set to "false"), "!pattern attr" is unclear which one it means. * we support attaching attributes to directories, but git-core internally does not currently make use of attributes on directories. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-15exclude: fix a bug in prefix compare optimizationLibravatar Nguyễn Thái Ngọc Duy1-0/+6
When "namelen" becomes zero at this stage, we have matched the fixed part, but whether it actually matches the pattern still depends on the pattern in "exclude". As demonstrated in t3001, path "three/a.3" exists and it matches the "three/a.3" part in pattern "three/a.3[abc]", but that does not mean a true match. Don't be too optimistic and let fnmatch() do the job. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-12grep: stop looking at random places for .gitattributesLibravatar Nguyễn Thái Ngọc Duy1-0/+22
grep searches for .gitattributes using "name" field in struct grep_source but that field is not real on-disk path name. For example, "grep pattern rev" fills the field with "rev:path", and Git looks for .gitattributes in the (non-existent but exploitable) path "rev:path" instead of "path". This patch passes real paths down to grep_source_load_driver() when: - grep on work tree - grep on the index - grep a commit (or a tag if it points to a commit) so that these cases look up .gitattributes at proper paths. .gitattributes lookup is disabled in all other cases. Initial-work-by: Jeff King <peff@peff.net> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-11test-lib: Fix say_color () not to interpret \a\b\c in the messageLibravatar Junio C Hamano1-1/+1
When running with color disabled (e.g. under prove to produce TAP output), say_color() helper function is defined to use echo to show the message. With a message that ends with "\c", echo is allowed to interpret it as "Do not end the line with LF". Use printf "%s\n" to emit the message literally. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-10Merge branch 'bw/cp-a-is-gnuism'Libravatar Junio C Hamano3-3/+3
* bw/cp-a-is-gnuism: tests: "cp -a" is a GNUism
2012-10-10svn test: escape peg revision separator using empty peg revLibravatar Jonathan Nieder1-1/+1
This test script uses "svn cp" to create a branch with an @-sign in its name: svn cp "pr ject/trunk" "pr ject/branches/not-a@{0}reflog" That sets up for later tests that fetch the branch and check that git svn mangles the refname appropriately. Unfortunately, modern svn versions interpret path arguments with an @-sign as an example of path@revision syntax (which pegs a path to a particular revision) and truncate the path or error out with message "svn: E205000: Syntax error parsing peg revision '{0}reflog'". When using subversion 1.6.x, escaping the @ sign as %40 avoids trouble (see 08fd28bb, 2010-07-08). Newer versions are stricter: $ svn cp "$repo/pr ject/trunk" "$repo/pr ject/branches/not-a%40{reflog}" svn: E205000: Syntax error parsing peg revision '%7B0%7Dreflog' The recommended method for escaping a literal @ sign in a path passed to subversion is to add an empty peg revision at the end of the path ("branches/not-a@{0}reflog@"). Do that. Pre-1.6.12 versions of Subversion probably treat the trailing @ as another literal @-sign (svn issue 3651). Luckily ever since v1.8.0-rc0~155^2~7 (t9118: workaround inconsistency between SVN versions, 2012-07-28) the test can survive that. Tested with Debian Subversion 1.6.12dfsg-6 and 1.7.5-1 and r1395837 of Subversion trunk (1.8.x). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-10git-send-email: introduce compose-encodingLibravatar Krzysztof Mazur1-0/+55
The introduction email (--compose option) have encoding hardcoded to UTF-8, but invoked editor may not use UTF-8 encoding. The encoding used by patches can be changed by the "8bit-encoding" option, but this option does not have effect on introduction email and equivalent for introduction email is missing. Added compose-encoding command line option and sendemail.composeencoding configuration option specify encoding of introduction email. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-09log --grep: use the same helper to set -E/-F options as "git grep"Libravatar Junio C Hamano1-0/+6
The command line option parser for "git log -F -E --grep='<ere>'" did not flip the "fixed" bit, violating the general "last option wins" principle among conflicting options. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-08tests: "cp -a" is a GNUismLibravatar Ben Walton3-3/+3
These tests just want a bit-for-bit identical copy; they do not need even -H (there is no symbolic link involved) nor -p (there is no funny permission or ownership issues involved). Just use "cp -R" instead. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-08Merge branch 'jc/maint-t1450-fsck-order-fix'Libravatar Junio C Hamano1-3/+1
The fsck test assumed too much on what kind of error it will detect. The only important thing is the inconsistency is detected as an error. * jc/maint-t1450-fsck-order-fix: t1450: the order the objects are checked is undefined