| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The naming convention was documented [1] but this script was not
renamed.
The original commit message indicates the script tests basic commit
functionality. Clean up the test name by changing the file name to
specify the intent as documented in the initial commit.
[1] f50c9f76c ("Rename some test scripts and describe the naming convention", 2005-05-15)
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Test fixes.
* sg/t7501-thinkofix:
t7501-commit: drop silly command substitution
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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'
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | |
| | |
| | |
| | |
| | | |
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"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
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
--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>
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
`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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"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
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"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>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 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
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| |/ /
| |
| |
| | |
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
|
|
| |
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>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
