summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-07-10test-lib: turn on ASan abort_on_error by defaultLibravatar Jeff King1-1/+1
By default, ASan will exit with code 1 when it sees an error. This means we'll notice a problem when we expected git to succeed, but not in a test_must_fail block. Let's ask it to actually raise SIGABRT instead. That will give us a signal death that test_must_fail will notice. As a bonus, it may also leave a coredump, which can be handy for digging into a failure. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-10test-lib: set ASAN_OPTIONS variable before we run gitLibravatar Jeff King1-3/+8
We turn off ASan's leak detection by default in the test suite because it's too noisy. But we don't do so until part-way through test-lib. This is before we've run any tests, but after we do our initial "./git" to see if the binary has even been built. When built with clang, this seems to work fine. However, using "gcc -fsanitize=address", the leak checker seems to complain more aggressively: $ ./git ... ==5352==ERROR: LeakSanitizer: detected memory leaks Direct leak of 2 byte(s) in 1 object(s) allocated from: #0 0x7f120e7afcf8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1cf8) #1 0x559fc2a3ce41 in do_xmalloc /home/peff/compile/git/wrapper.c:60 #2 0x559fc2a3cf1a in do_xmallocz /home/peff/compile/git/wrapper.c:100 #3 0x559fc2a3d0ad in xmallocz /home/peff/compile/git/wrapper.c:108 #4 0x559fc2a3d0ad in xmemdupz /home/peff/compile/git/wrapper.c:124 #5 0x559fc2a3d0ad in xstrndup /home/peff/compile/git/wrapper.c:130 #6 0x559fc274535a in main /home/peff/compile/git/common-main.c:39 #7 0x7f120dabd2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) This is a leak in the sense that we never free it, but it's in a global that is meant to last the whole program. So it's not really interesting or in need of fixing. And at any rate, mentioning leaks outside of the test_expect blocks is certainly unwelcome, as it pollutes stderr. Let's bump the setting of ASAN_OPTIONS higher in test-lib.sh to catch our initial "can we even run git?" test. While we're at it, we can add a comment to make it a bit less inscrutable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-24Merge branch 'sd/t3200-branch-m-test' into maintLibravatar Junio C Hamano1-0/+17
New test. * sd/t3200-branch-m-test: t3200: add test for single parameter passed to -m option
2017-06-24Merge branch 'km/test-mailinfo-b-failure' into maintLibravatar Junio C Hamano1-0/+42
New tests. * km/test-mailinfo-b-failure: t5100: add some more mailinfo tests
2017-06-24Merge branch 'ps/stash-push-pathspec-fix' into maintLibravatar Junio C Hamano1-0/+16
"git stash push <pathspec>" did not work from a subdirectory at all. Bugfix for a topic in v2.13 * ps/stash-push-pathspec-fix: git-stash: fix pushing stash with pathspec from subdir
2017-06-24Merge branch 'jk/pack-idx-corruption-safety' into maintLibravatar Junio C Hamano1-1/+7
A flaky test has been corrected. * jk/pack-idx-corruption-safety: t5313: make extended-table test more deterministic
2017-06-24Merge branch 'jk/diff-blob' into maintLibravatar Junio C Hamano2-0/+105
The result from "git diff" that compares two blobs, e.g. "git diff $commit1:$path $commit2:$path", used to be shown with the full object name as given on the command line, but it is more natural to use the $path in the output and use it to look up .gitattributes. * jk/diff-blob: diff: use blob path for blob/file diffs diff: use pending "path" if it is available diff: use the word "path" instead of "name" for blobs diff: pass whole pending entry in blobinfo handle_revision_arg: record paths for pending objects handle_revision_arg: record modes for "a..b" endpoints t4063: add tests of direct blob diffs get_sha1_with_context: dynamically allocate oc->path get_sha1_with_context: always initialize oc->symlink_path sha1_name: consistently refer to object_context as "oc" handle_revision_arg: add handle_dotdot() helper handle_revision_arg: hoist ".." check out of range parsing handle_revision_arg: stop using "dotdot" as a generic pointer handle_revision_arg: simplify commit reference lookups handle_revision_arg: reset "dotdot" consistently
2017-06-24Merge branch 'jc/name-rev-lw-tag' into maintLibravatar Junio C Hamano1-1/+1
"git describe --contains" penalized light-weight tags so much that they were almost never considered. Instead, give them about the same chance to be considered as an annotated tag that is the same age as the underlying commit would. * jc/name-rev-lw-tag: name-rev: favor describing with tags and use committer date to tiebreak name-rev: refactor logic to see if a new candidate is a better name
2017-06-13Merge branch 'ab/t3070-test-dedup' into maintLibravatar Junio C Hamano1-1/+0
Test cleanup. * ab/t3070-test-dedup: wildmatch test: remove redundant duplicate test
2017-06-13Merge branch 'jh/memihash-opt' into maintLibravatar Junio C Hamano1-5/+42
perf-test update. * jh/memihash-opt: p0004: don't error out if test repo is too small p0004: don't abort if multi-threaded is too slow p0004: use test_perf p0004: avoid using pipes p0004: simplify calls of test-lazy-init-name-hash
2017-06-13Merge branch 'tb/pull-ff-rebase-autostash' into maintLibravatar Junio C Hamano1-0/+18
"git pull --rebase --autostash" didn't auto-stash when the local history fast-forwards to the upstream. * tb/pull-ff-rebase-autostash: pull: ff --rebase --autostash works in dirty repo
2017-06-13Merge branch 'sl/clean-d-ignored-fix' into maintLibravatar Junio C Hamano2-0/+17
"git clean -d" used to clean directories that has ignored files, even though the command should not lose ignored ones without "-x". "git status --ignored" did not list ignored and untracked files without "-uall". These have been corrected. * sl/clean-d-ignored-fix: clean: teach clean -d to preserve ignored paths dir: expose cmp_name() and check_contains() dir: hide untracked contents of untracked dirs dir: recurse into untracked dirs for ignored files t7061: status --ignored should search untracked dirs t7300: clean -d should skip dirs with ignored files
2017-06-13Merge branch 'jc/skip-test-in-the-middle' into maintLibravatar Junio C Hamano2-50/+56
A recent update to t5545-push-options.sh started skipping all the tests in the script when a web server testing is disabled or unavailable, not just the ones that require a web server. Non HTTP tests have been salvaged to always run in this script. * jc/skip-test-in-the-middle: t5545: enhance test coverage when no http server is installed test: allow skipping the remainder
2017-06-13Merge branch 'bw/forking-and-threading' into maintLibravatar Junio C Hamano2-2/+44
The "run-command" API implementation has been made more robust against dead-locking in a threaded environment. * bw/forking-and-threading: usage.c: drop set_error_handle() run-command: restrict PATH search to executable files run-command: expose is_executable function run-command: block signals between fork and execve run-command: add note about forking and threading run-command: handle dup2 and close errors in child run-command: eliminate calls to error handling functions in child run-command: don't die in child when duping /dev/null run-command: prepare child environment before forking string-list: add string_list_remove function run-command: use the async-signal-safe execv instead of execvp run-command: prepare command before forking t0061: run_command executes scripts without a #! line t5550: use write_script to generate post-update hook
2017-06-13Merge branch 'jk/bug-to-abort' into maintLibravatar Junio C Hamano1-0/+6
Introduce the BUG() macro to improve die("BUG: ..."). * jk/bug-to-abort: usage: add NORETURN to BUG() function definitions config: complain about --local outside of a git repo setup_git_env: convert die("BUG") to BUG() usage.c: add BUG() function
2017-06-13Merge branch 'sb/checkout-recurse-submodules' into maintLibravatar Junio C Hamano3-8/+1
"git checkout --recurse-submodules" did not quite work with a submodule that itself has submodules. * sb/checkout-recurse-submodules: submodule: properly recurse for read-tree and checkout submodule: avoid auto-discovery in new working tree manipulator code submodule_move_head: reuse child_process structure for futher commands
2017-06-13git-stash: fix pushing stash with pathspec from subdirLibravatar Patrick Steinhardt1-0/+16
The `git stash push` command recently gained the ability to get a pathspec as its argument to only stash matching files. Calling this command from a subdirectory does not work, though, as one of the first things we do is changing to the top level directory without keeping track of the prefix from which the command is being run. Fix the shortcoming by storing the prefix previous to the call to `cd_to_toplevel` and then subsequently using `git rev-parse --prefix` to correctly resolve the pathspec. Add a test to catch future breakage of this usecase. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-13t3200: add test for single parameter passed to -m optionLibravatar Sahil Dua1-0/+17
Add a test for the case when only one parameter is passed to '-m' (move/rename) option. For example - if 'git branch -m bbb' is run while checked out on aaa branch, it should rename the currently checked out branch to bbb. There was no test for this particular case with only one parameter for -m option. However, there's one similar test case for -M option. Add test for making sure HEAD points to the bbb (new branch name). Also add a test for making sure the reflog that is moved to 'bbb' retains entries created for the currently checked out branch. Note that since the topmost entry on reflog for bbb will be about branch creation, we compare bbb@{1} (instead of bbb@{0}) with aaa@{0} to make sure the reflog for bbb retains entries from aaa. Signed-off-by: Sahil Dua <sahildua2305@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-12t5100: add some more mailinfo testsLibravatar Kyle J. McKay1-0/+42
Add some more simple mailinfo tests including a few that produce: fatal: `pos + len' is too far after the end of the buffer Mark those as 'test_expect_failure'. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-07t5313: make extended-table test more deterministicLibravatar Jeff King1-1/+7
Commit a1283866b (t5313: test bounds-checks of corrupted/malicious pack/idx files, 2016-02-25) added a test that requires our corrupted pack index to have two objects. The entry for the first one remains untouched, but we corrupt the entry for second one. Since the index stores the entries in sha1-sorted order, this means that the test must make sure that the sha1 of the object we expect to be corrupted ("$object") sorts after the other placeholder object. That commit used the HEAD commit as the placeholder, but the script never calls test_tick. That means that the commit object (and thus its sha1) depends on the timestamp when the test script is run. This usually works in practice, because the sha1 of $object starts with "fff". The commit object will sort after that only 1 in 4096 times, but when it does the test will fail. One obvious solution is to add the test_tick call to get a deterministic commit sha1. But since we're relying on the sort order for the test to function, let's make that very explicit by just generating a second blob with a known sha1. Reported-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-05Merge branch 'sd/t3200-typofix' into maintLibravatar Junio C Hamano1-1/+1
Test fix. * sd/t3200-typofix: branch test: fix invalid config key access
2017-06-05Merge branch 'sb/t5531-update-desc' into maintLibravatar Junio C Hamano1-2/+2
The description strings for a few tests have been updated. * sb/t5531-update-desc: t5531: fix test description
2017-06-05Merge branch 'tb/dedup-crlf-tests' into maintLibravatar Junio C Hamano2-187/+0
* tb/dedup-crlf-tests: t0027: tests are not expensive; remove t0025
2017-06-05Merge branch 'jk/alternate-ref-optim' into maintLibravatar Junio C Hamano1-1/+4
A test allowed both "git push" and "git receive-pack" on the other end write their traces into the same file. This is OK on platforms that allows atomically appending to a file opened with O_APPEND, but on other platforms led to a mangled output, causing intermittent test failures. This has been fixed by disabling traces from "receive-pack" in the test. * jk/alternate-ref-optim: t5400: avoid concurrent writes into a trace file
2017-06-05Merge branch 'bm/interpret-trailers-cut-line-is-eom' into maintLibravatar Junio C Hamano1-0/+17
"git interpret-trailers", when used as GIT_EDITOR for "git commit -v", looked for and appended to a trailer block at the very end, i.e. at the end of the "diff" output. The command has been corrected to pay attention to the cut-mark line "commit -v" adds to the buffer---the real trailer block should appear just before it. * bm/interpret-trailers-cut-line-is-eom: interpret-trailers: honor the cut line
2017-06-05Merge branch 'jn/clone-add-empty-config-from-command-line' into maintLibravatar Junio C Hamano1-0/+8
"git clone --config var=val" is a way to populate the per-repository configuration file of the new repository, but it did not work well when val is an empty string. This has been fixed. * jn/clone-add-empty-config-from-command-line: clone: handle empty config values in -c
2017-06-04Merge branch 'jt/use-trailer-api-in-commands' into maintLibravatar Junio C Hamano1-0/+44
"git cherry-pick" and other uses of the sequencer machinery mishandled a trailer block whose last line is an incomplete line. This has been fixed so that an additional sign-off etc. are added after completing the existing incomplete line. * jt/use-trailer-api-in-commands: sequencer: add newline before adding footers
2017-06-04Merge branch 'jt/push-options-doc' into maintLibravatar Junio C Hamano1-0/+37
The receive-pack program now makes sure that the push certificate records the same set of push options used for pushing. * jt/push-options-doc: receive-pack: verify push options in cert docs: correct receive.advertisePushOptions default
2017-06-04Merge branch 'js/eol-on-ourselves' into maintLibravatar Junio C Hamano7-25/+45
Make sure our tests would pass when the sources are checked out with "platform native" line ending convention by default on Windows. Some "text" files out tests use and the test scripts themselves that are meant to be run with /bin/sh, ought to be checked out with eol=LF even on Windows. * js/eol-on-ourselves: t4051: mark supporting files as requiring LF-only line endings Fix the remaining tests that failed with core.autocrlf=true t3901: move supporting files into t/t3901/ completion: mark bash script as LF-only git-new-workdir: mark script as LF-only Fix build with core.autocrlf=true
2017-06-04Merge branch 'jk/ignore-broken-tags-when-ignoring-missing-links' into maintLibravatar Junio C Hamano1-1/+26
Tag objects, which are not reachable from any ref, that point at missing objects were mishandled by "git gc" and friends (they should silently be ignored instead) * jk/ignore-broken-tags-when-ignoring-missing-links: revision.c: ignore broken tags with ignore_missing_links
2017-06-04Merge branch 'jk/disable-pack-reuse-when-broken' into maintLibravatar Junio C Hamano1-3/+45
"pack-objects" can stream a slice of an existing packfile out when the pack bitmap can tell that the reachable objects are all needed in the output, without inspecting individual objects. This strategy however would not work well when "--local" and other options are in use, and need to be disabled. * jk/disable-pack-reuse-when-broken: t5310: fix "; do" style pack-objects: disable pack reuse for object-selection options
2017-06-04Merge branch 'bw/submodule-with-bs-path' into maintLibravatar Junio C Hamano1-1/+1
A hotfix to a topic that is already in v2.13. * bw/submodule-with-bs-path: t7400: add !CYGWIN prerequisite to 'add with \\ in path'
2017-06-04Merge branch 'ah/log-decorate-default-to-auto' into maintLibravatar Junio C Hamano1-0/+12
Setting "log.decorate=false" in the configuration file did not take effect in v2.13, which has been corrected. * ah/log-decorate-default-to-auto: builtin/log: honor log.decorate
2017-06-04Merge branch 'ab/fix-poison-tests' into maintLibravatar Junio C Hamano15-34/+38
Update tests to pass under GETTEXT_POISON (a mechanism to ensure that output strings that should not be translated are not translated by mistake), and tell TravisCI to run them. * ab/fix-poison-tests: travis-ci: add job to run tests with GETTEXT_POISON travis-ci: setup "prove cache" in "script" step tests: fix tests broken under GETTEXT_POISON=YesPlease
2017-06-04Merge branch 'ab/doc-replace-gmane-links' into maintLibravatar Junio C Hamano1-1/+1
The Web interface to gmane news archive is long gone, even though the articles are still accessible via NTTP. Replace the links with ones to public-inbox.org. Because their message identification is based on the actual message-id, it is likely that it will be easier to migrate away from it if/when necessary. * ab/doc-replace-gmane-links: doc: replace more gmane links doc: replace a couple of broken gmane links
2017-06-01pull: ff --rebase --autostash works in dirty repoLibravatar Tyler Brazier1-0/+18
When `git pull --rebase --autostash` in a dirty repository resulted in a fast-forward, nothing was being autostashed and the pull failed. This was due to a shortcut to avoid running rebase when we can fast-forward, but autostash is ignored on that codepath. Now we will only take the shortcut if autostash is not in effect. Based on a few tests against the git.git repo, the shortcut does not seem to give us significant performance benefits, on Linux at least. Regardless, it is more important to be correct than to be fast. Signed-off-by: Tyler Brazier <tyler@tylerbrazier.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-29branch test: fix invalid config key accessLibravatar Sahil Dua1-1/+1
Fixes the test by changing "branch.s/s/dummy" to "branch.s/s.dummy" which is the right way of accessing config key "branch.s/s.dummy". Purpose of this test is to confirm that this key doesn't exist after the branch "s/s" has been renamed to "s". Earlier it was trying to access invalid config key and hence was getting an error. However, this wasn't caught because we were expecting the command to fail for other reason as mentioned above. Signed-off-by: Sahil Dua <sahildua2305@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-29wildmatch test: remove redundant duplicate testLibravatar Ævar Arnfjörð Bjarmason1-1/+0
Remove a test line that's exactly the same as the preceding line. This was brought in in commit feabcc173b ("Integrate wildmatch to git", 2012-10-15), these tests are originally copied from rsync.git, but the duplicate line was never present there, so must have just snuck in during integration with git by accident. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24diff: use blob path for blob/file diffsLibravatar Jeff King1-1/+6
When we diff a blob against a working tree file like: git diff HEAD:Makefile Makefile we always use the working tree filename for both sides of the diff. In most cases that's fine, as the two would be the same anyway, as above. And until recently, we used the "name" for the blob, not the path, which would have the messy "HEAD:" on the beginning. But when they don't match, like: git diff HEAD:old_path new_path it makes sense to show both names. This patch uses the blob's path field if it's available, and otherwise falls back to using the filename (in preference to the blob's name, which is likely to be garbage like a raw sha1). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24diff: use pending "path" if it is availableLibravatar Jeff King1-2/+2
There's a subtle distinction between "name" and "path" for a blob that we resolve: the name is what the user told us on the command line, and the path is what we traversed when finding the blob within a tree (if we did so). When we diff blobs directly, we use "name", but "path" is more likely to be useful to the user (it will find the correct .gitattributes, and give them a saner diff header). We still have to fall back to using the name for some cases (i.e., any blob reference that isn't of the form tree:path). That's the best we can do in such a case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24handle_revision_arg: record modes for "a..b" endpointsLibravatar Jeff King1-1/+1
The "a..b" revision syntax was designed to handle commits, so it doesn't bother to record any mode we find while traversing a "tree:path" endpoint. These days "git diff" can diff blobs using either "a:path..b:path" (with dots) or "a:path b:path" (without), but the two behave inconsistently, as the with-dots version fails to notice the mode. Let's teach the dot-dot range parser to record modes; it doesn't cost us anything, and it makes this case work. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24t4063: add tests of direct blob diffsLibravatar Jeff King1-0/+91
The git-diff command can directly compare two blobs (or a blob and a file), but we don't test this at all. Let's add some basic tests that reveal a few problems. There are basically four interesting inputs: 1. sha1 against sha1 (where diff has no information beyond the contents) 2. tree:path against tree:path (where it can get information via get_sha1_with_context) 3. Same as (2), but using the ".." range syntax 4. tree:path against a filename And beyond generating a sane diff, we care about a few little bits: which paths they show in the diff header, and whether they correctly pick up a mode change. They should all be able to show a mode except for (1), though note that case (3) is currently broken. For the headers, we would ideally show the path within the tree if we have it, making: git diff a:path b:path look the same as: git diff a b -- path We can't always do that (e.g., in the direct sha1/sha1 diff, we have no path to show), in which case we should fall back to the name that resolved to the blob (which is nonsense from the repository's perspective, but is the best we can do). Aside from the fallback case in (1), none of the cases get this right. Cases (2) and (3) always show the full tree:path, even though we should be able to know just the "path" portion. Case (4) picks up the filename path, but assigns it to _both_ sides of the diff. So this works for: git diff tree:path path but not for: git diff tree:other_path path The appropriate tests are marked to expect failure. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24handle_revision_arg: reset "dotdot" consistentlyLibravatar Jeff King1-0/+9
When we are parsing a range like "a..b", we write a temporary NUL over the first ".", so that we can access the names "a" and "b" as C strings. But our restoration of the original "." is done at inconsistent times, which can lead to confusing results. For most calls, we restore the "." after we resolve the names, but before we call verify_non_filename(). This means that when we later call add_pending_object(), the name for the left-hand "a" has been re-expanded to "a..b". You can see this with: git log --source a...b where "b" will be correctly marked with "b", but "a" will be marked with "a...b". Likewise with "a..b" (though you need to use --boundary to even see "a" at all in that case). To top off the confusion, when the REVARG_CANNOT_BE_FILENAME flag is set, we skip the non-filename check, and leave the NUL in place. That means we do report the correct name for "a" in the pending array. But some code paths try to show the whole "a...b" name in error messages, and these erroneously show only "a" instead of "a...b". E.g.: $ git cherry-pick HEAD:foo...HEAD:foo error: object d95f3ad14dee633a758d2e331151e950dd13e4ed is a blob, not a commit error: object d95f3ad14dee633a758d2e331151e950dd13e4ed is a blob, not a commit fatal: Invalid symmetric difference expression HEAD:foo (That last message should be "HEAD:foo...HEAD:foo"; I used cherry-pick because it passes the CANNOT_BE_FILENAME flag). As an interesting side note, cherry-pick actually looks at and re-resolves the arguments from the pending->name fields. So it would have been visibly broken by the first bug, but the effect was canceled out by the second one. This patch makes the whole function consistent by re-writing the NUL immediately after calling verify_non_filename(), and then restoring the "." as appropriate in some error-printing and early-return code paths. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24clean: teach clean -d to preserve ignored pathsLibravatar Samuel Lijin1-1/+1
There is an implicit assumption that a directory containing only untracked and ignored paths should itself be considered untracked. This makes sense in use cases where we're asking if a directory should be added to the git database, but not when we're asking if a directory can be safely removed from the working tree; as a result, clean -d would assume that an "untracked" directory containing ignored paths could be deleted, even though doing so would also remove the ignored paths. To get around this, we teach clean -d to collect ignored paths and skip an untracked directory if it contained an ignored path, instead just removing the untracked contents thereof. To achieve this, cmd_clean() has to collect all untracked contents of untracked directories, in addition to all ignored paths, to determine which untracked dirs must be skipped (because they contain ignored paths) and which ones should *not* be skipped. For this purpose, correct_untracked_entries() is introduced to prune a given dir_struct of untracked entries containing ignored paths and those untracked entries encompassed by the untracked entries which are not pruned away. A memory leak is also fixed in cmd_clean(). This also fixes the known breakage in t7300, since clean -d now skips untracked directories containing ignored paths. Signed-off-by: Samuel Lijin <sxlijin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-23t5531: fix test descriptionLibravatar Stefan Beller1-2/+2
The description of the test was not enclosed in single quotes, which broke the coloring scheme that I am used to. Upon closer inspection the test is good, but the description is a bit vague. So extend the description of the first test. While at it align the description of the file to match what we actually test in the file. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-22dir: hide untracked contents of untracked dirsLibravatar Samuel Lijin1-2/+2
When we taught read_directory_recursive() to recurse into untracked directories in search of ignored files given DIR_SHOW_IGNORED_TOO, that had the side effect of teaching it to collect the untracked contents of untracked directories. It doesn't always make sense to return these, though (we do need them for `clean -d`), so we introduce a flag (DIR_KEEP_UNTRACKED_CONTENTS) to control whether or not read_directory() strips dir->entries of the untracked contents of untracked dirs. We also introduce check_contains() to check if one dir_entry corresponds to a path which contains the path corresponding to another dir_entry. This also fixes known breakages in t7061, since status --ignored now searches untracked directories for ignored files. Signed-off-by: Samuel Lijin <sxlijin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-22t7061: status --ignored should search untracked dirsLibravatar Samuel Lijin1-2/+3
Per eb8c5b87, `status --ignored` by design does not list ignored files if they are in a directory which contains only ignored and untracked files (which is itself considered to be untracked) without `-uall`. This does not make sense for `--ignored`, which claims to "Show ignored files as well." Thus we revisit eb8c5b87 and decide that for such directories, `status --ignored` will list the directory as untracked *and* list all ignored files within said directory even without `-uall`. Signed-off-by: Samuel Lijin <sxlijin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-22t7300: clean -d should skip dirs with ignored filesLibravatar Samuel Lijin1-0/+16
If git sees a directory which contains only untracked and ignored files, clean -d should not remove that directory. It was recently discovered that this is *not* true of git clean -d, and it's possible that this has never worked correctly; this test and its accompanying patch series aims to fix that. Signed-off-by: Samuel Lijin <sxlijin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-20revision.c: ignore broken tags with ignore_missing_linksLibravatar Jeff King1-1/+26
When peeling a tag for prepare_revision_walk(), we do not respect the ignore_missing_links flag. This can lead to a bogus error when pack-objects walks the possibly-broken unreachable-but-recent part of the object graph. The other link-following all happens via traverse_commit_list(), which explains why this case was missed. And our tests covered only broken links from commits. Let's be more comprehensive and cover broken tree entries (which do work) and tags (which shows off this bug). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-18interpret-trailers: honor the cut lineLibravatar Brian Malehorn1-0/+17
If a commit message is edited with the "verbose" option, the buffer will have a cut line and diff after the log message, like so: my subject # ------------------------ >8 ------------------------ # Do not touch the line above. # Everything below will be removed. diff --git a/foo.txt b/foo.txt index 5716ca5..7601807 100644 --- a/foo.txt +++ b/foo.txt @@ -1 +1 @@ -bar +baz "git interpret-trailers" is unaware of the cut line, and assumes the trailer block would be at the end of the whole thing. This can easily be seen with: $ GIT_EDITOR='git interpret-trailers --in-place --trailer Acked-by:me' \ git commit --amend -v Teach "git interpret-trailers" to notice the cut-line and ignore the remainder of the input when looking for a place to add new trailer block. This makes it consistent with how "git commit -v -s" inserts a new Signed-off-by: line. This can be done by the same logic as the existing helper function, wt_status_truncate_message_at_cut_line(), uses, but it wants the caller to pass a strbuf to it. Because the function ignore_non_trailer() used by the command takes a <pointer, length> pair, not a strbuf, steal the logic from wt_status_truncate_message_at_cut_line() to create a new wt_status_locate_end() helper function that takes <pointer, length> pair, and make ignore_non_trailer() call it to help "interpret-trailers". Since there is only one caller of wt_status_truncate_message_at_cut_line() in cmd_commit(), rewrite it to call wt_status_locate_end() helper instead and remove the old helper that no longer has any caller. Signed-off-by: Brian Malehorn <bmalehorn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>