git/t/t7502-commit.sh, branch v1.8.2.2

git-commit: only append a newline to -m mesg if necessary

2013-02-19T17:30:50Z

Currently, git will append two newlines to every message supplied via the -m switch. The purpose of this is to allow -m to be supplied multiple times and have each supplied string become a paragraph in the resulting commit message. Normally, this does not cause a problem since any trailing newlines will be removed by the cleanup operation. If cleanup=verbatim for example, then the trailing newlines will not be removed and will survive into the resulting commit message. Instead, let's ensure that the string supplied to -m is newline terminated, but only append a second newline when appending additional messages. Fixes the test in t7502. Signed-off-by: Brandon Casey Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

t7502: demonstrate breakage with a commit message with trailing newlines

2013-02-19T17:30:23Z

This test attempts to verify that a commit message supplied to 'git commit' via the -m switch was used in full as the commit message for a commit when --cleanup=verbatim was used. But, this test has been broken since it was introduced. Since the commit message containing trailing newlines was supplied to 'git commit' using a command substitution, the trailing newlines were removed by the shell. This means that a string without any trailing newlines was actually supplied to 'git commit'. The test was able to complete successfully since internally, git appends two newlines to each string supplied via the -m switch. So, the two newlines removed by the shell were then re-added by git, and the resulting commit matched what was expected. So, let's move the initial creation of the commit message string out from within a previous test so that it stands alone. Assign the desired commit message to a variable using literal newlines. Then populate the expect file from the contents of the commit message variable. This way the shell variable becomes the authoritative source of the commit message and can be supplied via the -m switch with the trailing newlines intact. Mark this test as failing, since it is not handled correctly by git. As described above, git appends two extra newlines to every string supplied via -m, even to the ones that already end with a newline. Signed-off-by: Brandon Casey Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

t/t7502: compare entire commit message with what was expected

2013-02-19T17:29:13Z

This test attempts to verify that a commit in "verbatim" mode, when supplied a commit template, produces a commit in which the commit message matches exactly the template that was supplied. But, since the commit operation appends additional instructions for the user as comments in the commit buffer, which would cause the comparison to fail, this test decided to compare only the first three lines (the length of the template) of the resulting commit message to the original template file. This has two problems. 1. It does not allow the template to be lengthened or shortened without also modifying the number of lines that are considered significant (i.e. the argument to 'head -n'). 2. It will not catch a bug in git that causes git to append additional lines to the commit message. So, let's use the --no-status option to 'git commit' which will cause git to refrain from appending the lines of instructional text to the commit message. This will allow the entire resulting commit message to be compared against the expected value. Signed-off-by: Brandon Casey Signed-off-by: Junio C Hamano

Merge branch 'jc/custom-comment-char'

2013-02-04T18:23:49Z

Allow a configuration variable core.commentchar to customize the character used to comment out the hint lines in the edited text from the default '#'. * jc/custom-comment-char: Allow custom "comment char"

Allow custom "comment char"

2013-01-16T20:48:22Z

Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of # form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano Signed-off-by: Ralf Thielow Signed-off-by: Junio C Hamano

commit: make default of "cleanup" option configurable

2013-01-10T19:45:02Z

The default of the "cleanup" option in "git commit" is not configurable. Users who don't want to use the default have to pass this option on every commit since there's no way to configure it. This commit introduces a new config option "commit.cleanup" which can be used to change the default of the "cleanup" option in "git commit". Signed-off-by: Ralf Thielow Signed-off-by: Junio C Hamano

t7502: factor out autoident prerequisite

2012-11-16T01:47:24Z

t7502 checks the behavior of commit when we can and cannot determine a valid committer ident. Let's move that into test-lib as a lazy prerequisite so other scripts can use it. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

t7502: test early quit from commit with bad ident

2012-07-26T21:23:35Z

In commit f20f387, "git commit" notices and dies much earlier when we have a bogus commit identity. That commit did not add a test because we cannot do so reliably (namely, we can only trigger the behavior on a system where the automatically generated identity is bogus). However, now that we have a prerequisite check for this feature, we can add a test that will at least run on systems that produce such a bogus identity. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

t7502: handle systems where auto-identity is broken

2012-07-26T21:23:35Z

Test t7502.21 checks whether we write the committer name into COMMIT_EDITMSG when it has been automatically determined. However, not all systems can produce valid automatic identities. Prior to f20f387 (commit: check committer identity more strictly), this test worked even when we did not have a valid automatic identity, since it did not run the strict test until after we had generated the template. That commit tightened the check to fail early (since we would fail later, anyway), meaning that systems without a valid GECOS name or hostname would fail the test. We cannot just work around this, because it depends on configuration outside the control of the test script. Therefore we introduce a new test_prerequisite to run this test only on systems where automatic ident works at all. As a result, we can drop the confusing test_must_fail bit from the test. The intent was that by giving "git commit" invalid input (namely, nothing to commit), that it would stop at a predictable point, whether we had a valid identity or not, from which we could view the contents of COMMIT_EDITMSG. Since that assumption no longer holds, and we can only run the test when we have a valid identity, there is no reason not to let commit run to completion. That lets us be more robust to other unforeseen failures. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

t7502: drop confusing test_might_fail call

2012-07-26T21:23:35Z

In t7502.20, we run "git commit" and check that it warns us that the author and committer identity are not the same (this is always the case in the test environment, since we set up the idents differently). Instead of actually making a commit, we have a clean index, so the "git commit" we run will fail. This is marked as might_fail, which is not really correct; it will always fail since there is nothing to commit. However, the only reason not to do a complete commit would be to see the intermediate state of the COMMIT_EDITMSG file when the commit is not completed. We don't need to care about this, though; even a complete commit will leave COMMIT_EDITMSG for us to view. By doing a real commit and dropping the might_fail, we are more robust against other unforeseen failures of "git commit" that might influence our test result. It might seem less robust to depend on the fact that "git commit" leaves COMMIT_EDITMSG in place after a successful commit. However, that brings this test in line with others parts of the script, which make the same assumption. Furthermore, if that ever does change, the right solution is not to prevent commit from completing, but to set EDITOR to a script that will record the contents we see. After all, the point of these tests is to check what the user sees in their EDITOR, so that would be the most direct test. For now, though, we can continue to use the "shortcut" that COMMIT_EDITMSG is left intact. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano