summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-09-22Sync with 2.13.6Libravatar Junio C Hamano1-0/+48
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Sync with 2.12.5Libravatar Junio C Hamano1-0/+48
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Sync with 2.11.4Libravatar Junio C Hamano1-0/+48
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Sync with 2.10.5Libravatar Junio C Hamano1-0/+48
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Merge branch 'jk/git-shell-drop-cvsserver' into maint-2.10Libravatar Junio C Hamano1-0/+48
2017-09-12shell: drop git-cvsserver support by defaultLibravatar Jeff King1-0/+48
The git-cvsserver script is old and largely unmaintained these days. But git-shell allows untrusted users to run it out of the box, significantly increasing its attack surface. Let's drop it from git-shell's list of internal handlers so that it cannot be run by default. This is not backwards compatible. But given the age and development activity on CVS-related parts of Git, this is likely to impact very few users, while helping many more (i.e., anybody who runs git-shell and had no intention of supporting CVS). There's no configuration mechanism in git-shell for us to add a boolean and flip it to "off". But there is a mechanism for adding custom commands, and adding CVS support here is fairly trivial. Let's document it to give guidance to anybody who really is still running cvsserver. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-10Merge branch 'hv/t5526-andand-chain-fix' into maintLibravatar Junio C Hamano1-4/+4
Test fix. * hv/t5526-andand-chain-fix: t5526: fix some broken && chains
2017-09-10Merge branch 'rs/t1002-do-not-use-sum' into maintLibravatar Junio C Hamano2-35/+35
Test simplification. * rs/t1002-do-not-use-sum: t1002: stop using sum(1)
2017-09-10Merge branch 'rs/t3700-clean-leftover' into maintLibravatar Junio C Hamano1-0/+1
A test fix. * rs/t3700-clean-leftover: t3700: fix broken test under !POSIXPERM
2017-09-10Merge branch 'ab/ref-filter-no-contains' into maintLibravatar Junio C Hamano1-1/+1
A test fix. * ab/ref-filter-no-contains: tests: don't give unportable ">" to "test" built-in, use -gt
2017-09-10Merge branch 'rs/archive-excluded-directory' into maintLibravatar Junio C Hamano1-3/+44
"git archive" did not work well with pathspecs and the export-ignore attribute. We may want to resurrect the "we don't archive an empty directory" bonus patch, but I do not mind merging the above early to 'next' and leave it as a separate follow-up enhancement. cf. <20170820090629.tumvqwzkromcykjf@sigill.intra.peff.net> * rs/archive-excluded-directory: archive: don't queue excluded directories archive: factor out helper functions for handling attributes t5001: add tests for export-ignore attributes and exclude pathspecs
2017-09-10Merge branch 'mg/killed-merge' into maintLibravatar Junio C Hamano1-0/+15
Killing "git merge --edit" before the editor returns control left the repository in a state with MERGE_MSG but without MERGE_HEAD, which incorrectly tells the subsequent "git commit" that there was a squash merge in progress. This has been fixed. * mg/killed-merge: merge: save merge state earlier merge: split write_merge_state in two merge: clarify call chain Documentation/git-merge: explain --continue
2017-09-10Merge branch 'tb/apply-with-crlf' into maintLibravatar Junio C Hamano1-6/+27
"git apply" that is used as a better "patch -p1" failed to apply a taken from a file with CRLF line endings to a file with CRLF line endings. The root cause was because it misused convert_to_git() that tried to do "safe-crlf" processing by looking at the index entry at the same path, which is a nonsense---in that mode, "apply" is not working on the data in (or derived from) the index at all. This has been fixed. * tb/apply-with-crlf: apply: file commited with CRLF should roundtrip diff and apply convert: add SAFE_CRLF_KEEP_CRLF
2017-09-10Merge branch 'as/grep-quiet-no-match-exit-code-fix' into maintLibravatar Junio C Hamano1-0/+5
"git grep -L" and "git grep --quiet -L" reported different exit codes; this has been corrected. * as/grep-quiet-no-match-exit-code-fix: git-grep: correct exit code with --quiet and -L
2017-09-10Merge branch 'pw/am-signoff' into maintLibravatar Junio C Hamano1-20/+63
"git am -s" has been taught that some input may end with a trailer block that is not Signed-off-by: and it should refrain from adding an extra blank line before adding a new sign-off in such a case. * pw/am-signoff: am: fix signoff when other trailers are present
2017-09-10Merge branch 'rs/in-obsd-basename-dirname-take-const' into maintLibravatar Junio C Hamano1-2/+16
Portability fix. * rs/in-obsd-basename-dirname-take-const: test-path-utils: handle const parameter of basename and dirname
2017-09-10Merge branch 'rs/t4062-obsd' into maintLibravatar Junio C Hamano1-1/+3
Test portability fix. * rs/t4062-obsd: t4062: use less than 256 repetitions in regex
2017-09-10Merge branch 'rs/obsd-getcwd-workaround' into maintLibravatar Junio C Hamano1-2/+28
Test portability fix for BSDs. * rs/obsd-getcwd-workaround: t0001: skip test with restrictive permissions if getpwd(3) respects them
2017-09-10Merge branch 'bw/clone-recursive-quiet' into maintLibravatar Junio C Hamano1-0/+6
"git clone --recurse-submodules --quiet" did not pass the quiet option down to submodules. * bw/clone-recursive-quiet: clone: teach recursive clones to respect -q
2017-09-10Merge branch 'pw/sequence-rerere-autoupdate' into maintLibravatar Junio C Hamano2-45/+132
Commands like "git rebase" accepted the --rerere-autoupdate option from the command line, but did not always use it. This has been fixed. * pw/sequence-rerere-autoupdate: cherry-pick/revert: reject --rerere-autoupdate when continuing cherry-pick/revert: remember --rerere-autoupdate t3504: use test_commit rebase -i: honor --rerere-autoupdate rebase: honor --rerere-autoupdate am: remember --rerere-autoupdate setting
2017-09-10Merge branch 'bw/push-options-recursively-to-submodules' into maintLibravatar Junio C Hamano1-1/+24
"git push --recurse-submodules $there HEAD:$target" was not propagated down to the submodules, but now it is. * bw/push-options-recursively-to-submodules: submodule--helper: teach push-check to handle HEAD
2017-09-10Merge branch 'ma/pager-per-subcommand-action' into maintLibravatar Junio C Hamano1-0/+80
The "tag.pager" configuration variable was useless for those who actually create tag objects, as it interfered with the use of an editor. A new mechanism has been introduced for commands to enable pager depending on what operation is being carried out to fix this, and then "git tag -l" is made to run pager by default. If this works out OK, I think there are low-hanging fruits in other commands like "git branch" that outputs long list in one mode while taking input in another. * ma/pager-per-subcommand-action: git.c: ignore pager.* when launching builtin as dashed external tag: change default of `pager.tag` to "on" tag: respect `pager.tag` in list-mode only t7006: add tests for how git tag paginates git.c: provide setup_auto_pager() git.c: let builtins opt for handling `pager.foo` themselves builtin.h: take over documentation from api-builtin.txt
2017-09-10Merge branch 'jk/rev-list-empty-input' into maintLibravatar Junio C Hamano2-11/+15
"git log --tag=no-such-tag" showed log starting from HEAD, which has been fixed---it now shows nothing. * jk/rev-list-empty-input: revision: do not fallback to default when rev_input_given is set rev-list: don't show usage when we see empty ref patterns revision: add rev_input_given flag t6018: flesh out empty input/output rev-list tests
2017-09-10Merge branch 'st/lib-gpg-kill-stray-agent' into maintLibravatar Junio C Hamano1-0/+1
Some versions of GnuPG fails to kill gpg-agent it auto-spawned and such a left-over agent can interfere with a test. Work it around by attempting to kill one before starting a new test. * st/lib-gpg-kill-stray-agent: t: lib-gpg: flush gpg agent on startup
2017-08-23Merge branch 'jt/t1450-fsck-corrupt-packfile' into maintLibravatar Junio C Hamano1-0/+16
A test update. * jt/t1450-fsck-corrupt-packfile: tests: ensure fsck fails on corrupt packfiles
2017-08-23Merge branch 'jb/t8008-cleanup' into maintLibravatar Junio C Hamano1-14/+16
Code clean-up. * jb/t8008-cleanup: t8008: rely on rev-parse'd HEAD instead of sha1 value
2017-08-23Merge branch 'jt/subprocess-handshake' into maintLibravatar Junio C Hamano2-101/+293
Code cleanup. * jt/subprocess-handshake: sub-process: refactor handshake to common function Documentation: migrate sub-process docs to header convert: add "status=delayed" to filter process protocol convert: refactor capabilities negotiation convert: move multiple file filter error handling to separate function convert: put the flags field before the flag itself for consistent style t0021: write "OUT <size>" only on success t0021: make debug log file name configurable t0021: keep filter log files on comparison
2017-08-23Merge branch 'jk/reflog-walk' into maintLibravatar Junio C Hamano3-12/+136
Numerous bugs in walking of reflogs via "log -g" and friends have been fixed. * jk/reflog-walk: reflog-walk: apply --since/--until to reflog dates reflog-walk: stop using fake parents rev-list: check reflog_info before showing usage get_revision_1(): replace do-while with an early return log: do not free parents when walking reflog log: clarify comment about reflog cycles revision: disallow reflog walking with revs->limited t1414: document some reflog-walk oddities
2017-08-23Merge branch 'jk/ref-filter-colors' into maintLibravatar Junio C Hamano6-72/+175
"%C(color name)" in the pretty print format always produced ANSI color escape codes, which was an early design mistake. They now honor the configuration (e.g. "color.ui = never") and also tty-ness of the output medium. * jk/ref-filter-colors: ref-filter: consult want_color() before emitting colors pretty: respect color settings for %C placeholders rev-list: pass diffopt->use_colors through to pretty-print for-each-ref: load config earlier color: check color.ui in git_default_config() ref-filter: pass ref_format struct to atom parsers ref-filter: factor out the parsing of sorting atoms ref-filter: make parse_ref_filter_atom a private function ref-filter: provide a function for parsing sort options ref-filter: move need_color_reset_at_eol into ref_format ref-filter: abstract ref format into its own struct ref-filter: simplify automatic color reset t: use test_decode_color rather than literal ANSI codes docs/for-each-ref: update pointer to color syntax check return value of verify_ref_format()
2017-08-23merge: save merge state earlierLibravatar Michael J Gruber1-0/+15
If the `git merge` process is killed while waiting for the editor to finish, the merge state is lost but the prepared merge msg and tree is kept. So, a subsequent `git commit` creates a squashed merge even when the user asked for proper merge commit originally. Demonstrate the problem with a test crafted after the in t7502. The test requires EXECKEEPSPID (thus does not run under MINGW). Save the merge state earlier (in the non-squash case) so that it does not get lost. This makes the test pass. Reported-by: hIpPy <hippy2981@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19apply: file commited with CRLF should roundtrip diff and applyLibravatar Torsten Bögershausen1-6/+27
When a file had been commited with CRLF but now .gitattributes say "* text=auto" (or core.autocrlf is true), the following does not roundtrip, `git apply` fails: printf "Added line\r\n" >>file && git diff >patch && git checkout -- . && git apply patch Before applying the patch, the file from working tree is converted into the index format (clean filter, CRLF conversion, ...). Here, when commited with CRLF, the line endings should not be converted. Note that `git apply --index` or `git apply --cache` doesn't call convert_to_git() because the source material is already in index format. Analyze the patch if there is a) any context line with CRLF, or b) if any line with CRLF is to be removed. In this case the patch file `patch` has mixed line endings, for a) it looks like this: diff --git a/one b/one index 533790e..c30dea8 100644 --- a/one +++ b/one @@ -1 +1,2 @@ a\r +b\r And for b) it looks like this: diff --git a/one b/one index 533790e..485540d 100644 --- a/one +++ b/one @@ -1 +1 @@ -a\r +b\r If `git apply` detects that the patch itself has CRLF, (look at the line " a\r" or "-a\r" above), the new flag crlf_in_old is set in "struct patch" and two things will happen: - read_old_data() will not convert CRLF into LF by calling convert_to_git(..., SAFE_CRLF_KEEP_CRLF); - The WS_CR_AT_EOL bit is set in the "white space rule", CRLF are no longer treated as white space. While at there, make it clear that read_old_data() in apply.c knows what it wants convert_to_git() to do with respect to CRLF. In fact, this codepath is about applying a patch to a file in the filesystem, which may not exist in the index, or may exist but may not match what is recorded in the index, or in the extreme case, we may not even be in a Git repository. If convert_to_git() peeked at the index while doing its work, it *would* be a bug. Pass NULL instead of &the_index to convert_to_git() to make sure we catch future bugs to clarify this. Update the test in t4124: split one test case into 3: - Detect the " a\r" line in the patch - Detect the "-a\r" line in the patch - Use LF in repo and CLRF in the worktree. Reported-by: Anthony Sottile <asottile@umich.edu> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19archive: don't queue excluded directoriesLibravatar René Scharfe1-2/+2
Reject directories with the attribute export-ignore already while queuing them. This prevents read_tree_recursive() from descending into them and this avoids write_archive_entry() rejecting them later on, which queue_or_write_archive_entry() is not prepared for. Borrow the existing strbuf to build the full path to avoid string copies and extra allocations; just make sure we restore the original value before moving on. Keep checking any other attributes in write_archive_entry() as before, but avoid checking them twice. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19t5001: add tests for export-ignore attributes and exclude pathspecsLibravatar René Scharfe1-3/+44
Demonstrate mishandling of the attribute export-ignore by git archive when used together with pathspecs. Wildcard pathspecs can even cause it to abort. And a directory excluded without a wildcard is still included as an empty folder in the archive. Test-case-by: David Adam <zanchey@ucc.gu.uwa.edu.au> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-17git-grep: correct exit code with --quiet and -LLibravatar Anthony Sottile1-0/+5
The handling of `status_only` no longer interferes with the handling of `unmatch_name_only`. `--quiet` no longer affects the exit code when using `-L`/`--files-without-match`. Signed-off-by: Anthony Sottile <asottile@umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-17t5526: fix some broken && chainsLibravatar Heiko Voigt1-4/+4
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15t1002: stop using sum(1)Libravatar René Scharfe2-35/+35
sum(1) is a command for calculating checksums of the contents of files. It was part of early editions of Unix ("Research Unix", 1972/1973, [1]). cksum(1) appeared in 4.4BSD (1993) as a replacement [2], and became part of POSIX.1-2008 [3]. OpenBSD 5.6 (2014) removed sum(1). We only use sum(1) in t1002 to check for changes in three files. On MinGW we use md5sum(1) instead. We could switch to the standard command cksum(1) for all platforms; MinGW comes with GNU coreutils now, which provides sum(1), cksum(1) and md5sum(1). Use our standard method for checking for file changes instead: test_cmp. It's more convenient because it shows differences nicely, it's faster on MinGW because we have a special implementation there based only on shell-internal commands, it's simpler as it allows us to avoid stripping out unnecessary entries from the checksum file using grep(1), and it's more consistent with the rest of the test suite. We already compare changed files with their expected new contents using diff(1), so we don't need to check with "test_must_fail test_cmp" if they differ from their original state. A later patch could convert the direct diff(1) calls to test_cmp as well. With all sum(1) calls gone, remove the MinGW-specific implementation from test-lib.sh as well. [1] http://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man1/sum.1 [2] http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/share/man/cat1/cksum.0 [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cksum.html Signed-off-by: René Scharfe <l.s.r@web.de> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-09t4062: use less than 256 repetitions in regexLibravatar René Scharfe1-1/+3
OpenBSD's regex library has a repetition limit (RE_DUP_MAX) of 255. That's the minimum acceptable value according to POSIX. In t4062 we use 4096 repetitions in the test "-G matches", though, causing it to fail. Combine two repetition operators, both less than 256, to arrive at 4096 zeros instead of using a single one, to fix the test on OpenBSD. Original-patch-by: David Coppa <dcoppa@openbsd.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-08t3700: fix broken test under !POSIXPERMLibravatar René Scharfe1-0/+1
76e368c378 (t3700: fix broken test under !SANITY) explains that the test 'git add --chmod=[+-]x changes index with already added file' can fail if xfoo3 is still present as a symlink from a previous test and deletes it with rm(1). That still leaves it present in the index, which causes the test to fail if POSIXPERM is not defined. Get rid of it by calling "git reset --hard" as well, as 76e368c378 already mentioned in passing. Helped-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-08am: fix signoff when other trailers are presentLibravatar Phillip Wood1-20/+63
If there was no 'Signed-off-by:' trailer but another trailer such as 'Reported-by:' then 'git am --signoff' would add a blank line between the existing trailers and the added 'Signed-off-by:' line. e.g. Rebase accepts '--rerere-autoupdate' as an option but only honors it if '-m' is also given. Fix it for a non-interactive rebase by passing on the option to 'git am' and 'git cherry-pick'. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Fix by using the code provided for this purpose in sequencer.c. Change the tests so that they check the formatting of the 'Signed-off-by:' lines rather than just grepping for them. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-07test-path-utils: handle const parameter of basename and dirnameLibravatar René Scharfe1-2/+16
The parameter to basename(3) and dirname(3) traditionally had the type "char *", but on OpenBSD it's been "const char *" for years. That causes (at least) Clang to throw an incompatible-pointer-types warning for test-path-utils, where we try to pass around pointers to these functions. Avoid this warning (which is fatal in DEVELOPER mode) by ignoring the promise of OpenBSD's implementations to keep input strings unmodified and enclosing them in POSIX-compatible wrappers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-07t0001: skip test with restrictive permissions if getpwd(3) respects themLibravatar René Scharfe1-2/+28
The sub-test "init in long base path" in t0001 checks the ability to handle long base paths with restrictive permissions (--x). On OpenBSD getcwd(3) fails in that case even for short paths. Check the two aspects separately by trying to use a long base path both with and without execute-only permissions. Only attempt the former if we know that getcwd(3) doesn't care. Original-patch-by: David Coppa <dcoppa@openbsd.org> Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-07tests: don't give unportable ">" to "test" built-in, use -gtLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change an argument to test_line_count (which'll ultimately be turned into a "test" expression) to use "-gt" instead of ">" for an arithmetic test. This broken on e.g. OpenBSD as of v2.13.0 with my commit ac3f5a3468 ("ref-filter: add --no-contains option to tag/branch/for-each-ref", 2017-03-24). Downstream just worked around it by patching git and didn't tell us about it, I discovered this when reading various Git packaging implementations: https://github.com/openbsd/ports/commit/7e48bf88a20 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-04Merge tag 'v2.13.5' into maintLibravatar Junio C Hamano4-2/+57
2017-08-04clone: teach recursive clones to respect -qLibravatar Brandon Williams1-0/+6
Teach 'git clone --recurse-submodules' to respect the '-q' option by passing down the quiet flag to the process which handles cloning of submodules. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03git.c: ignore pager.* when launching builtin as dashed externalLibravatar Martin Ågren1-1/+1
When running, e.g., `git -c alias.bar=foo bar`, we expand the alias and execute `git-foo` as a dashed external. This is true even if git foo is a builtin. That is on purpose, and is motivated in a comment which was added in commit 441981bc ("git: simplify environment save/restore logic", 2016-01-26). Shortly before we launch a dashed external, and unless we have already found out whether we should use a pager, we check `pager.foo`. This was added in commit 92058e4d ("support pager.* for external commands", 2011-08-18). If the dashed external is a builtin, this does not match that commit's intention and is arguably wrong, since it would be cleaner if we let the "dashed external builtin" handle `pager.foo`. This has not mattered in practice, but a recent patch taught `git-tag` to ignore `pager.tag` under certain circumstances. But, when started using an alias, it doesn't get the chance to do so, as outlined above. That recent patch added a test to document this breakage. Do not check `pager.foo` before launching a builtin as a dashed external, i.e., if we recognize the name of the external as a builtin. Change the test to use `test_expect_success`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03tag: change default of `pager.tag` to "on"Libravatar Martin Ågren1-14/+14
The previous patch taught `git tag` to only respect `pager.tag` in list-mode. That patch left the default value of `pager.tag` at "off". After that patch, it makes sense to let the default value be "on" instead, since it will help with listing many tags, but will not hurt users of `git tag -a` as it would have before. Make that change. Update documentation and tests. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03tag: respect `pager.tag` in list-mode onlyLibravatar Martin Ågren1-1/+14
Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. Someone who makes use of both `git tag -a` and `git tag -l` will probably not set `pager.tag`, so that `git tag -a` will actually work, at the cost of not paging output of `git tag -l`. Use the mechanisms introduced in two earlier patches to ignore `pager.tag` in git.c and let the `git tag` builtin handle it on its own. Only respect `pager.tag` when running in list-mode. There is a window between where the pager is started before and after this patch. This means that early errors can behave slightly different before and after this patch. Since operation-parsing has to happen inside this window, this can be seen with `git -c pager.tag="echo pager is used" tag -l --unknown-option`. This change in paging-behavior should be acceptable since it only affects erroneous usages. Update the documentation and update tests. If an alias is used to run `git tag -a`, then `pager.tag` will still be respected. Document this known breakage. It will be fixed in a later commit. Add a similar test for `-l`, which works. Noticed-by: Anatoly Borodin <anatoly.borodin@gmail.com> Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03t7006: add tests for how git tag paginatesLibravatar Martin Ågren1-0/+67
Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. Someone who makes use of both `git tag -a` and `git tag -l` will probably not set `pager.tag`, so that `git tag -a` will actually work, at the cost of not paging output of `git tag -l`. Since we're about to change how `git tag` respects `pager.tag`, add tests around this, including how the configuration is ignored if --no-pager or --paginate are used. Construct tests with a few different subcommands. First, use -l. Second, use "no arguments" and --contains, since those imply -l. (There are more arguments which imply -l, but using these two should be enough.) Third, use -a as a representative for "not -l". Actually, the tests use `git tag -am` so no editor is launched, but that is irrelevant, since we just want to see whether the pager is used or not. Make one of the tests demonstrate the broken behavior mentioned above, where `git tag -a` respects `pager.tag`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-02revision: do not fallback to default when rev_input_given is setLibravatar Jeff King1-0/+6
If revs->def is set (as it is in "git log") and there are no pending objects after parsing the user's input, then we show whatever is in "def". But if the user _did_ ask for some input that just happened to be empty (e.g., "--glob" that does not match anything), showing the default revision is confusing. We should just show nothing, as that is what the user's request yielded. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-02rev-list: don't show usage when we see empty ref patternsLibravatar Jeff King1-3/+3
If the user gives us no starting point for a traversal, we want to complain with our normal usage message. But if they tried to do so with "--all" or "--glob", but that happened not to match any refs, the usage message isn't helpful. We should just give them the empty output they asked for instead. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>