git/t/t7501-commit.sh, branch v2.19.2

Merge branch 'jk/trailer-fixes' into maint

2018-11-21T13:57:42Z

"git interpret-trailers" and its underlying machinery had a buggy code that attempted to ignore patch text after commit log message, which triggered in various codepaths that will always get the log message alone and never get such an input. * jk/trailer-fixes: append_signoff: use size_t for string offsets sequencer: ignore "---" divider when parsing trailers pretty, ref-filter: format %(trailers) with no_divider option interpret-trailers: allow suppressing "---" divider interpret-trailers: tighten check for "---" patch boundary trailer: pass process_trailer_opts to trailer_info_get() trailer: use size_t for iterating trailer list trailer: use size_t for string offsets

Merge branch 'sg/t7501-thinkofix'

2018-08-27T21:33:48Z

Test fixes. * sg/t7501-thinkofix: t7501-commit: drop silly command substitution

Merge branch 'sg/test-must-be-empty'

2018-08-27T21:33:43Z

Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp ' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null ' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'

sequencer: ignore "---" divider when parsing trailers

2018-08-23T17:08:51Z

When the sequencer code appends a signoff or cherry-pick origin, it uses the default trailer-parsing options, which treat "---" as the end of the commit message. As a result, it may be fooled by a commit message that contains that string and fail to find the existing trailer block. Even more confusing, the actual append code does not know about "---", and always appends to the end of the string. This can lead to bizarre results. E.g., appending a signoff to a commit message like this: subject body --- these dashes confuse the parser! Signed-off-by: A results in output with a final block like: Signed-off-by: A Signed-off-by: A The parser thinks the final line of the message is "body", and ignores everything else, claiming there are no trailers. So we output an extra newline separator (wrong) and add a duplicate signoff (also wrong). Since we know we are feeding a pure commit message, we can simply tell the parser to ignore the "---" divider. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

t7501-commit: drop silly command substitution

2018-08-22T15:39:31Z

The test '--dry-run with conflicts fixed from a merge' in 't7501-commit.sh', added in 8dc874b2ee (wt-status.c: set commitable bit if there is a meaningful merge., 2016-02-15), runs the following unnecessary and downright bogus command substitution: ! $(git merge --no-commit commit-1) && I.e. after 'git merge ...' is executed and expectedly fails, the test attempts to execute its output: Merging: 80f2ea2 commit 2 virtual commit-1 found 1 common ancestor: e60d113 Initial commit Auto-merging test-file CONFLICT (content): Merge conflict in test-file Automatic merge failed; fix conflicts and then commit the result. as a command, which most likely fails, because there is no such command as "Merging:". Then '!' negates the failed exit status, the test continues, and eventually succeeds. Remove this command substitution and use 'test_must_fail' to ensure that 'git merge' fails. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

tests: use 'test_must_be_empty' instead of 'test_cmp '

2018-08-21T18:48:36Z

Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

t7000-t7999: fix broken &&-chains

2018-07-16T21:38:47Z

Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

t: use test_write_lines() instead of series of 'echo' commands

2018-07-03T19:38:04Z

These tests employ a noisy subshell (with missing &&-chain) to feed input into Git commands or files: (echo a; echo b; echo c) | git some-command ... Simplify by taking advantage of test_write_lines(): test_write_lines a b c | git some-command ... Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

commit: allow partial commits with relative paths

2018-04-05T08:05:48Z

Commit 8894d53580 (commit: allow partial commits with relative paths, 2011-07-30) ensured that partial commits were allowed when a user supplies a relative pathspec but then this was regressed in 5879f5684c (remove prefix argument from pathspec_prefix, 2011-09-04) when the prefix argument to 'pathspec_prefix' removed and the 'list_paths' function wasn't properly adjusted to cope with the change, resulting in over-eager pruning of the tree that is overlayed on the index. This fixes the regression and adds a regression test so this can be prevented in the future. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

status: contextually notify user about an initial commit

2017-06-22T02:10:27Z

The existing message, "Initial commit", makes sense for the commit template notifying users that it's their initial commit, but is confusing when merely checking the status of a fresh repository (or orphan branch) without having any commits yet. Change the output of "status" to say "No commits yet" when "git status" is run on a fresh repo (or orphan branch), while retaining the current "Initial commit" message displayed in the template that's displayed in the editor when the initial commit is being authored. Correspondingly change the output of "short status" to "No commits yet on " when "git status -sb" is run on a fresh repo (or orphan branch). A few alternatives considered were, * Waiting for initial commit * Your current branch does not have any commits * Current branch waiting for initial commit The most succint one among the alternatives was chosen. [with help on tests from Ævar] Helped-by: Junio C Hamano Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano