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

Merge branch 'ss/commit-dry-run-resolve-merge-to-no-op'

2016-05-23T21:54:28Z

"git commit --dry-run" reported "No, no, you cannot commit." in one case where "git commit" would have allowed you to commit, and this improves it a little bit ("git commit --dry-run --short" still does not give you the correct answer, for example). This is a stop-gap measure in that "commit --short --dry-run" still gives an incorrect result. * ss/commit-dry-run-resolve-merge-to-no-op: wt-status.c: set commitable bit if there is a meaningful merge.

commit: do not ignore an empty message given by -m ''

2016-04-07T20:25:12Z

When f9568530 (builtin-commit: resurrect behavior for multiple -m options, 2007-11-11) converted a "char *message" to "struct strbuf message" to hold the messages given with the "-m" option, it incorrectly changed the checks "did we get a message with the -m option?" to "is message.len 0?". Later, we noticed one breakage from this change and corrected it with 25206778 (commit: don't start editor if empty message is given with -m, 2013-05-25). However, "we got a message with -m, even though an empty one, so we shouldn't be launching an editor" was not the only breakage. * "git commit --amend -m '' --allow-empty", even though it looks strange, is a valid request to amend the commit to have no message at all. Due to the misdetection of the presence of -m on the command line, we ended up keeping the log messsage from the original commit. * "git commit -m "$msg" -F file" should be rejected whether $msg is an empty string or not, but due to the same bug, was not rejected when $msg is empty. * "git -c template=file -m "$msg"" should ignore the template even when $msg is empty, but it didn't and instead used the contents from the template file. Correct these by checking have_option_m, which the earlier 25206778 introduced to fix the same bug. Reported-by: Adam Dinwoodie Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

commit: --amend -m '' silently fails to wipe message

2016-04-07T20:21:43Z

`git commit --amend -m ''` seems to be an unambiguous request to blank a commit message, but it actually leaves the commit message as-is. That's the case regardless of whether `--allow-empty-message` is specified, and doesn't so much as drop a non-zero return code. Add failing tests to show this behaviour. Signed-off-by: Adam Dinwoodie Signed-off-by: Junio C Hamano

wt-status.c: set commitable bit if there is a meaningful merge.

2016-02-17T16:53:11Z

The 'commit --dry-run' and 'commit' return values differed if a conflicted merge had been resolved and the resulting commit would record the same tree as the parent. Update show_merge_in_progress to set the commitable bit if conflicts have been resolved and a merge is in progress. Signed-off-by: Stephen P. Smith Signed-off-by: Junio C Hamano

commit: accept more date formats for "--date"

2014-05-02T21:15:22Z

Right now we pass off the string found by "--date" straight to the fmt_ident function, which will use our strict parse_date to normalize it. However, this means obvious things like "--date=now" or "--date=2.days.ago" will not work. Instead, let's fallback to the approxidate function to handle this for us. Note that we must try parse_date ourselves first, even though approxidate will try strict parsing itself. The reason is that approxidate throws away any timezone information it sees from the strict parsing, and we want to preserve it. So asking for: git commit --date="@1234567890 -0700" continues to set the date in -0700, regardless of what the local timezone is. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

commit: print "Date" line when the user has set date

2014-05-02T21:14:21Z

When we make a commit and the author is not the same as the committer (e.g., because you used "-c $commit" or "--author=$somebody"), we print the author's name and email in both the commit-message template and as part of the commit summary. This is a safety check to give the user a chance to confirm that we are doing what they expect. This patch brings the same safety for the "date" field, which may be set by "-c" or by using "--date". Note that we explicitly do not set it for $GIT_AUTHOR_DATE, as it is probably not of interest when "git commit" is being fed its parameters by a script. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

demonstrate git-commit --dry-run exit code behaviour

2014-02-24T17:16:53Z

In particular, show that --short and --porcelain, while implying --dry-run, do not return the same exit code as --dry-run. This is due to the wt_status.commitable flag being set only when a long status is requested. No fix is provided here; with [1], it should be trivial to fix though - just a matter of calling wt_status_mark_commitable(). [1] http://article.gmane.org/gmane.comp.version-control.git/242489 Signed-off-by: Tay Ray Chuan Signed-off-by: Junio C Hamano

t7501: fix "empty commit" test with NO_PERL

2014-01-23T21:11:07Z

t7501.9 tries to check that "git commit" will fail when the index is unchanged. It relies on previous tests not to have modified the index. When it was originally written, this was always the case. However, commit c65dc35 (t7501: test the right kind of breakage, 2012-03-30) changed earlier tests (4 and 5) to leave a modification in the index. We never noticed, however, because t7501.7, between the two, clears the index state as a side effect. However, that test depends on the PERL prerequisite, and so it does not always run. Therefore if NO_PERL is set, we do not run the intervening test, the index is left unclean, and t7501.9 fails. We could fix this by moving t7501.9 up in the script. However, this patch instead leaves it in place and adds a "git reset" before the commit. This makes the test more explicit about its preconditions, and will future-proof it against any other changes in the test state. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Make test "using invalid commit with -C" more strict

2013-08-25T06:58:43Z

In the test 'using invalid commit with -C' git-commit would have failed even if the -C option had been given the correct commit, as there was nothing to commit. Pass --allow-empty to make sure it would make a commit, were there no issues with the argument given to the -C option. Signed-off-by: Kacper Kornet Signed-off-by: Junio C Hamano

Test 'commit --only' after 'checkout --orphan'

2013-06-02T19:31:17Z

There are some index handling subtleties in 'commit --only' that are best tested when we have an existing index, but an unborn or empty HEAD. These circumstances are easily produced by 'checkout --orphan', but we did not previously have a test for it. The main expected failure mode would be: erroneously loading the existing index contents when building the temporary index that is used for --only. Cf. http://article.gmane.org/gmane.comp.version-control.git/225969 and subsequent discussion. Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano