summaryrefslogtreecommitdiff
path: root/t/t7501-commit.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-10-19Merge branch 'ss/wt-status-committable'Libravatar Junio C Hamano1-2/+8
Code clean-up in the internal machinery used by "git status" and "git commit --dry-run". * ss/wt-status-committable: roll wt_status_state into wt_status and populate in the collect phase wt-status.c: set the committable flag in the collect phase t7501: add test of "commit --dry-run --short" wt-status: rename commitable to committable wt-status.c: move has_unmerged earlier in the file
2018-09-17Merge branch 'jk/trailer-fixes'Libravatar Junio C Hamano1-0/+16
"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
2018-09-07wt-status.c: set the committable flag in the collect phaseLibravatar Stephen P. Smith1-3/+3
In an update to fix a bug with "commit --dry-run" it was found that the committable flag was broken. The update was, at the time, accepted as it was better than the previous version. [1] Since the setting of the committable flag had been done in wt_longstatus_print_updated, move it to wt_status_collect_updated_cb. Set the committable flag in wt_status_collect_changes_initial to keep from introducing a rebase regression. Instead of setting the committable flag in show_merge_in_progress, in wt_status_cllect check for a merge that has not been committed. If present then set the committable flag. Change the tests to expect success since updates to the wt-status broken code section is being fixed. [1] https://public-inbox.org/git/xmqqr3gcj9i5.fsf@gitster.mtv.corp.google.com/ Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-07t7501: add test of "commit --dry-run --short"Libravatar Stephen P. Smith1-0/+6
Add test for commit with --dry-run --short for a new file of zero length. The test demonstrates that the setting of the committable flag is broken. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/t7501-thinkofix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t7501-thinkofix: t7501-commit: drop silly command substitution
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano1-4/+2
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-23sequencer: ignore "---" divider when parsing trailersLibravatar Jeff King1-0/+16
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-22t7501-commit: drop silly command substitutionLibravatar SZEDER Gábor1-1/+1
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 <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'Libravatar SZEDER Gábor1-4/+2
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 <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t7000-t7999: fix broken &&-chainsLibravatar Eric Sunshine1-26/+26
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t: use test_write_lines() instead of series of 'echo' commandsLibravatar Eric Sunshine1-2/+2
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 <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05commit: allow partial commits with relative pathsLibravatar Brandon Williams1-0/+12
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 <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-21status: contextually notify user about an initial commitLibravatar Kaartic Sivaraam1-1/+1
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 <gitster@pobox.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-19Merge branch 'ak/commit-only-allow-empty'Libravatar Junio C Hamano1-0/+9
"git commit --allow-empty --only" (no pathspec) with dirty index ought to be an acceptable way to create a new commit that does not change any paths, but it was forbidden, perhaps because nobody needed it so far. * ak/commit-only-allow-empty: commit: remove 'Clever' message for --only --amend commit: make --only --allow-empty work without paths
2016-12-05commit: make --only --allow-empty work without pathsLibravatar Andreas Krey1-0/+9
--only is implied when paths are present, and required them unless --amend. But with --allow-empty it should be allowed as well - it is the only way to create an empty commit in the presence of staged changes. Signed-off-by: Andreas Krey <a.krey@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-29sequencer: use trailer's trailer layoutLibravatar Jonathan Tan1-0/+36
Make sequencer use trailer.c's trailer layout definition, as opposed to parsing the footer by itself. This makes "commit -s", "cherry-pick -x", and "format-patch --signoff" consistent with trailer, allowing non-trailer lines and multiple-line trailers in trailer blocks under certain conditions, and therefore suppressing the extra newline in those cases. Consistency with trailer extends to respecting trailer configs. Tests have been included to show that. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-23Merge branch 'ss/commit-dry-run-resolve-merge-to-no-op'Libravatar Junio C Hamano1-0/+20
"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.
2016-04-07commit: do not ignore an empty message given by -m ''Libravatar Jeff King1-3/+3
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 <adam@dinwoodie.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-07commit: --amend -m '' silently fails to wipe messageLibravatar Adam Dinwoodie1-0/+20
`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 <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17wt-status.c: set commitable bit if there is a meaningful merge.Libravatar Stephen P. Smith1-0/+20
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 <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02commit: accept more date formats for "--date"Libravatar Jeff King1-2/+10
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02commit: print "Date" line when the user has set dateLibravatar Jeff King1-0/+5
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24demonstrate git-commit --dry-run exit code behaviourLibravatar Tay Ray Chuan1-0/+36
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 <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23t7501: fix "empty commit" test with NO_PERLLibravatar Jeff King1-0/+1
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-24Make test "using invalid commit with -C" more strictLibravatar Kacper Kornet1-1/+1
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 <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02Test 'commit --only' after 'checkout --orphan'Libravatar Thomas Rast1-0/+13
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 <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-15Merge branch 'jk/maint-commit-amend-only-no-paths'Libravatar Junio C Hamano1-0/+10
"git commit --amend --only --" was meant to allow "Clever" people to rewrite the commit message without making any change even when they have already changes for the next commit added to their index, but it never worked as advertised since it was introduced in 1.3.0 era. * jk/maint-commit-amend-only-no-paths: commit: fix "--amend --only" with no pathspec
2012-07-15Merge branch 'cw/amend-commit-without-message'Libravatar Junio C Hamano1-0/+15
"commit --amend" used to refuse amending a commit with an empty log message, with or without "--allow-empty-message". * cw/amend-commit-without-message: Allow edit of empty message with commit --amend
2012-07-13Merge branch 'jc/refactor-diff-stdin'Libravatar Junio C Hamano1-0/+12
Due to the way "git diff --no-index" is bolted onto by touching the low level code that is shared with the rest of the "git diff" code, even though it has to work in a very different way, any comparison that involves a file "-" at the root level incorrectly tried to read from the standard input. This cleans up the no-index codepath further to remove code that reads from the standard input from the core side, which is never necessary when git is running its usual diff operation. * jc/refactor-diff-stdin: diff-index.c: "git diff" has no need to read blob from the standard input diff-index.c: unify handling of command line paths diff-index.c: do not pretend paths are pathspecs
2012-07-10commit: fix "--amend --only" with no pathspecLibravatar Jeff King1-0/+10
When we do not have any pathspec, we typically disallow an explicit "--only", because it makes no sense (your commit would, by definition, be empty). But since 6a74642 (git-commit --amend: two fixes., 2006-04-20), we have allowed "--amend --only" with the intent that it would amend the commit, ignoring any contents staged in the index. However, while that commit allowed the combination, we never actually implemented the logic to make it work. The current code notices that we have no pathspec and assumes we want to do an as-is commit (i.e., the "--only" is ignored). Instead, we must make sure to follow the partial-commit code-path. We also need to tweak the list_paths function to handle a NULL pathspec. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Allow edit of empty message with commit --amendLibravatar Chris Webb1-0/+15
"git commit --amend" used on a commit with an empty message fails unless -m is given, whether or not --allow-empty-message is specified. Allow it to proceed to the editor with an empty commit message. Unless --allow-empty-message is in force, it will still abort later if an empty message is saved from the editor (this check was already necessary to prevent a non-empty commit message being edited to an empty one). Add a test for --amend --edit of an empty commit message which fails without this fix, as it's a rare case that won't get frequently tested otherwise. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-28diff-index.c: "git diff" has no need to read blob from the standard inputLibravatar Junio C Hamano1-0/+12
Only "diff --no-index -" does. Bolting the logic into the low-level function diff_populate_filespec() was a layering violation from day one. Move populate_from_stdin() function out of the generic diff.c to its only user, diff-index.c. Also make sure "-" from the command line stays a special token "read from the standard input", even if we later decide to sanitize the result from prefix_filename() function in a few obvious ways, e.g. removing unnecessary "./" prefix, duplicated slashes "//" in the middle, etc. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-30commit: rephrase the error when user did not touch templated log messageLibravatar Junio C Hamano1-0/+6
When the user exited editor without editing the commit log template given by "git commit -t <template>", the commit was aborted (correct) with an error message that said "due to empty commit message" (incorrect). This was because the original template support was done by piggybacking on the check to detect an empty log message. Split the codepaths into two independent checks to clarify the error. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-30commit: do not trigger bogus "has templated message edited" checkLibravatar Junio C Hamano1-0/+6
When "-t template" and "-F msg" options are both given (or worse yet, there is "commit.template" configuration but a message is given in some other way), the documentation says that template is ignored. However, the "has the user edited the message?" check still used the contents of the template file as the basis of the emptyness check. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-30t7501: test the right kind of breakageLibravatar Junio C Hamano1-0/+2
These tests try to run "git commit" with various "forbidden" combinations of options and expect the command to fail, but they do so without having any change added to the index. We wouldn't be able to catch breakages that would allow these combinations by mistake with them because the command will fail with "nothing to commit" anyway. Make sure we have something added to the index before running the command. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08test: commit --amend should honor --no-editLibravatar Jonathan Nieder1-0/+40
A quick test to make sure git doesn't lose the functionality added by the recent patch "commit: honor --no-edit", plus another test to check the classical --edit use case (use with "-m"). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08t7501 (commit): modernize styleLibravatar Jonathan Nieder1-133/+127
Put the opening quote starting each test on the same line as the test_expect_* invocation. While at it: - guard commands that prepare test input for individual tests in the same test_expect_success, so their scope is clearer and errors at that stage can be caught; - use the compare_diff_patch helper function when comparing patches; - use single-quotes in preference to double-quotes and <<\EOF in preference to <<EOF, to save readers the trouble of looking for variable interpolations; - lift the setting of the $author variable used throughout the test script to the top of the test script; - include "setup" in the titles of test assertions that prepare for later ones to make it more obvious which tests can be skipped; - use test_must_fail instead of "if ...; then:; else false; fi", for clarity and to catch segfaults when they happen; - break up some pipelines into separate commands that read and write to ordinary files, and test the exit status at each stage; - chain commands with &&. Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain; - combine two initial tests that do not make as much sense alone. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08test: remove a porcelain test that hard-codes commit namesLibravatar Jonathan Nieder1-20/+0
The rev-list output in this test depends on the details of test_tick's dummy dates and the choice of hash function. Worse, it depends on the order and nature of commits made in the earlier tests, so adding new tests or rearranging existing ones breaks it. It would be nice to check that "git commit" and commit-tree name objects consistently and that commit objects' text is as documented, but this particular test checks everything at once and hence is not a robust test for that. Remove it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08test: add missing "&&" after echo commandLibravatar Jonathan Nieder1-6/+7
This test wants to modify a file and commit the change, but because of a missing separator between commands it is parsed as a single "echo" command. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-16Merge branch 'ci/commit--interactive-atomic'Libravatar Junio C Hamano1-4/+17
* ci/commit--interactive-atomic: Test atomic git-commit --interactive Add commit to list of config.singlekey commands Add support for -p/--patch to git-commit Allow git commit --interactive with paths t7501.8: feed a meaningful command Use a temporary index for git commit --interactive
2011-05-10Test atomic git-commit --interactiveLibravatar Conrad Irwin1-0/+10
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09Allow git commit --interactive with pathsLibravatar Conrad Irwin1-2/+3
Make git commit --interactive feel more like git add --interactive by allowing the user to restrict the list of files they have to deal with. A test in t7501 used to ensure that this is not allowed; no need for that anymore. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09t7501.8: feed a meaningful commandLibravatar Jeff King1-4/+6
The command expects "git commit --interactive <path>" to fail because you cannot (yet) limit "commit --interactive" with a pathspec, but even if the command allowed to take <path>, the test would have failed as saying just 7:quit would leave the index the same as the current commit, leading to an attempt to create an empty commit that would fail without --allow-empty. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13i18n: use test_i18ngrep in t7501Libravatar Junio C Hamano1-3/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-status "Initial commit" messageLibravatar Ævar Arnfjörð Bjarmason1-2/+5
Gettextize the "# Initial commit" message. A test in t7501-commit.sh explicitly checked for this message. Change it to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-20ident: die on bogus date formatLibravatar Jeff King1-0/+4
If the user gives "git commit --date=foobar", we silently ignore the --date flag. We should note the error. This patch puts the fix at the lowest level of fmt_ident, which means it also handles GIT_AUTHOR_DATE=foobar, as well. There are two down-sides to this approach: 1. Technically this breaks somebody doing something like "git commit --date=now", which happened to work because bogus data is the same as "now". Though we do explicitly handle the empty string, so anybody passing an empty variable through the environment will still work. If the error is too much, perhaps it can be downgraded to a warning? 2. The error checking happens _after_ the commit message is written, which can be annoying to the user. We can put explicit checks closer to the beginning of git-commit, but that feels a little hack-ish; suddenly git-commit has to care about how fmt_ident works. Maybe we could simply call fmt_ident earlier? Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-12commit --amend: copy notes to the new commitLibravatar Thomas Rast1-0/+12
Teaches 'git commit --amend' to copy notes. The catch is that this must also be guarded by --no-post-rewrite, which we use to prevent --amend from copying notes during a rebase -i 'edit'/'reword'. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'jk/warn-author-committer-after-commit'Libravatar Junio C Hamano1-1/+5
* jk/warn-author-committer-after-commit: user_ident_sufficiently_given(): refactor the logic to be usable from elsewhere commit.c::print_summary: do not release the format string too early commit: allow suppression of implicit identity advice commit: show interesting ident information in summary strbuf: add strbuf_addbuf_percentquote strbuf_expand: convert "%%" to "%" Conflicts: builtin-commit.c ident.c
2010-01-14commit: show interesting ident information in summaryLibravatar Jeff King1-1/+5
There are a few cases of user identity information that we consider interesting: (1) When the author and committer identities do not match. (2) When the committer identity was picked automatically from the username, hostname and GECOS information. In these cases, we already show the information in the commit message template. However, users do not always see that template because they might use "-m" or "-F". With this patch, we show these interesting cases after the commit, along with the subject and change summary. The new output looks like: $ git commit \ -m "federalist papers" \ --author='Publius <alexander@hamilton.com>' [master 3d226a7] federalist papers Author: Publius <alexander@hamilton.com> 1 files changed, 1 insertions(+), 0 deletions(-) for case (1), and: $ git config --global --unset user.name $ git config --global --unset user.email $ git commit -m foo [master 7c2a927] foo Committer: Jeff King <peff@c-71-185-130-222.hsd1.va.comcast.net> Your name and email address were configured automatically based on your username and hostname. Please check that they are accurate. You can suppress this message by setting them explicitly: git config --global user.name Your Name git config --global user.email you@example.com If the identity used for this commit is wrong, you can fix it with: git commit --amend --author='Your Name <you@example.com>' 1 files changed, 1 insertions(+), 0 deletions(-) for case (2). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03builtin-commit: add --date optionLibravatar Miklos Vajna1-0/+15
This is like --author: allow a user to specify a given date without using the GIT_AUTHOR_DATE environment variable. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>