summaryrefslogtreecommitdiff
path: root/t/t7102-reset.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-02-05reset: support "--mixed --intent-to-add" modeLibravatar Nguyễn Thái Ngọc Duy1-0/+15
When --mixed is used, entries could be removed from index if the target ref does not have them. When "reset" is used in preparation for commit spliting (in a dirty worktree), it could be hard to track what files to be added back. The new option --intent-to-add simplifies it by marking all removed files intent-to-add. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
2013-07-12Merge branch 'as/log-output-encoding-in-user-format'Libravatar Junio C Hamano1-5/+34
"log --format=" did not honor i18n.logoutputencoding configuration and this attempts to fix it. * as/log-output-encoding-in-user-format: t4205 (log-pretty-formats): avoid using `sed` t6006 (rev-list-format): add tests for "%b" and "%s" for the case i18n.commitEncoding is not set t4205, t6006, t7102: make functions better readable t4205 (log-pretty-formats): revert back single quotes t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1 t4205: replace .\+ with ..* in sed commands pretty: --format output should honor logOutputEncoding pretty: Add failing tests: --format output should honor logOutputEncoding t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs t7102 (reset): don't hardcode SHA-1 in expected outputs t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
2013-07-05t4205, t6006, t7102: make functions better readableLibravatar Alexey Shumkin1-4/+6
Function 'test_format' has become harder to read after its change in de6029a2 (pretty: Add failing tests: --format output should honor logOutputEncoding, 2013-06-26). Simplify it by moving its "should we expect it to fail?" parameter to the end. Note, current code does not use this last parameter as far as there are no tests expected to fail. We can keep that for future use. Also, reformat comments. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Improved-by: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1Libravatar Alexey Shumkin1-5/+5
Both "iso8859-1" and "iso-8859-1" are understood as latin-1 by modern platforms, but the latter is not understood by older platforms;update tests to use the former. This is in line with 3994e8a9 (t4201: use ISO8859-1 rather than ISO-8859-1, 2009-12-03), which did the same. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26pretty: --format output should honor logOutputEncodingLibravatar Alexey Shumkin1-1/+1
One can set an alias $ git config [--global] alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset' --abbrev-commit --date=local" to see the log as a pretty tree (like *gitk* but in a terminal). However, log messages written in an encoding i18n.commitEncoding which differs from terminal encoding are shown corrupted even when i18n.logOutputEncoding and terminal encoding are the same (e.g. log messages committed on a Cygwin box with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa). To simplify an example we can say the following two commands are expected to give the same output to a terminal: $ git log --oneline --no-color $ git log --pretty=format:'%h %s' However, the former pays attention to i18n.logOutputEncoding configuration, while the latter does not when it formats "%s". The same corruption is true for $ git diff --submodule=log and $ git rev-list --pretty=format:%s HEAD and $ git reset --hard This patch makes pretty --format honor logOutputEncoding when it formats log message. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26pretty: Add failing tests: --format output should honor logOutputEncodingLibravatar Alexey Shumkin1-2/+27
One can set an alias $ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset' --abbrev-commit --date=local" to see the log as a pretty tree (like *gitk* but in a terminal). However, log messages written in an encoding i18n.commitEncoding which differs from terminal encoding are shown corrupted even when i18n.logOutputEncoding and terminal encoding are the same (e.g. log messages committed on a Cygwin box with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa). To simplify an example we can say the following two commands are expected to give the same output to a terminal: $ git log --oneline --no-color $ git log --pretty=format:'%h %s' However, the former pays attention to i18n.logOutputEncoding configuration, while the latter does not when it formats "%s". The same corruption is true for $ git diff --submodule=log and $ git rev-list --pretty=format:%s HEAD and $ git reset --hard This patch adds failing tests for the next patch that fixes them. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26t7102 (reset): don't hardcode SHA-1 in expected outputsLibravatar Alexey Shumkin1-3/+5
The expected SHA-1 digests are always available in variables. Use them instead of hardcoding. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-09test: test_must_be_empty helperLibravatar Junio C Hamano1-1/+1
There are quite a lot places where an output file is expected to be empty, and we fail the test when it is not. The output from running the test script with -i -v can be helped if we showed the unexpected contents at that point. We could of course do >expected.empty && test_cmp expected.empty actual but this is commmon enough to be done with a dedicated helper. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Merge branch 'as/test-cleanup'Libravatar Junio C Hamano1-20/+21
* as/test-cleanup: t7102 (reset): don't hardcode SHA-1 in expected outputs
2013-01-24t7102 (reset): don't hardcode SHA-1 in expected outputsLibravatar Alexey Shumkin1-20/+21
Take the expected SHA-1 digest in a variable, and use it instead of hardcoding when checking the result. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-15reset $sha1 $pathspec: require $sha1 only to be treeishLibravatar Martin von Zweigbergk1-0/+8
Resetting with paths does not update HEAD and there is nothing else that a commit should be needed for. Relax the argument parsing so only a tree is required. The sha1 is only passed to read_from_tree(), which already only requires a tree. The "rev" variable we pass to run_add_interactive() will resolve to a tree. This is fine since interactive_reset only needs the parameter to be a treeish and doesn't use it for display purposes. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-15reset $pathspec: exit with code 0 if successfulLibravatar Martin von Zweigbergk1-6/+12
"git reset $pathspec" currently exits with a non-zero exit code if the worktree is dirty after resetting, which is inconsistent with reset without pathspec, and it makes it harder to know whether the command really failed. Change it to exit with code 0 regardless of whether the worktree is dirty so that non-zero indicates an error. This makes the 4 "disambiguation" test cases in t7102 clearer since they all used to "fail", 3 of which "failed" due to changes in the work tree. Now only the ambiguous one fails. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-13reset [<commit>] paths...: do not mishandle unmerged pathsLibravatar Junio C Hamano1-0/+15
Because "diff --cached HEAD" showed an incorrect blob object name on the LHS of the diff, we ended up updating the index entry with bogus value, not what we read from the tree. Noticed by John Nowak. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13i18n: use test_i18ncmp and test_i18ngrep in t7102 and t7110Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-reset "Unstaged changes after reset" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize the ""Unstaged changes after reset:" message. A test in t7102-reset.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>
2009-12-30Merge branch 'maint-1.6.1' into maintLibravatar Junio C Hamano1-7/+7
* maint-1.6.1: textconv: stop leaking file descriptors commit: --cleanup is a message option git count-objects: handle packs bigger than 4G t7102: make the test fail if one of its check fails Conflicts: builtin-commit.c diff.c
2009-12-29t7102: make the test fail if one of its check failsLibravatar Nguyễn Thái Ngọc Duy1-7/+7
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-21reset: make the reminder output consistent with "checkout"Libravatar Matthieu Moy1-1/+2
git reset without argument displays a summary of the local modification, like this: $ git reset Makefile: locally modified Some people have problems with this; they look like an error message. This patch makes its output mimic how "git checkout $another_branch" reports the paths with local modifications. "git add --refresh --verbose" is changed in the same way. It also adds a header to make it clear that the output is informative, and not an error. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
2008-09-03tests: use "git xyzzy" form (t7000 - t7199)Libravatar Nanako Shiraishi1-2/+2
Converts tests between t7001-t7103. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-20"needs update" considered harmfulLibravatar Junio C Hamano1-1/+1
"git update-index --refresh", "git reset" and "git add --refresh" have reported paths that have local modifications as "needs update" since the beginning of git. Although this is logically correct in that you need to update the index at that path before you can commit that change, it is now becoming more and more clear, especially with the continuous push for user friendliness since 1.5.0 series, that the message is suboptimal. After all, the change may be something the user might want to get rid of, and "updating" would be absolutely a wrong thing to do if that is the case. I prepared two alternatives to solve this. Both aim to reword the message to more neutral "locally modified". This patch is a more intrusive variant that changes the message for only Porcelain commands ("add" and "reset") while keeping the plumbing "update-index" intact. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-24/+24
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-25Allow "git-reset path" when unambiguousLibravatar Junio C Hamano1-0/+47
Resetting a selected set of index entries is done with "git reset -- paths" syntax, but we did not allow -- to be omitted even when the command is unambiguous. This updates the command to follow the general rule: * When -- appears, revs come before it, and paths come after it; * When there is no --, earlier ones are revs and the rest are paths, and we need to guess. When lack of -- marker forces us to guess, we protect from user errors and typoes by making sure what we treat as revs do not appear as filenames in the work tree, and what we treat as paths do appear as filenames in the work tree, and by erroring out if that is not the case. We tell the user to disambiguate by using -- in such a case. which is employed elsewhere in the system. When this rule is applied to "reset", because we can have only zero or one rev to the command, the check can be slightly simpler than other programs. We have to check only the first one or two tokens after the command name and options, and when they are: -- A: no explicit rev given; "A" and whatever follows it are paths. A --: explicit rev "A" given and whatever follows the "--" are paths. A B: "A" could be rev or path and we need to guess. "B" could be missing but if exists that (and everything that follows) would be paths. So we apply the guess only in the last case and only to "A" (not "B" and what comes after it). * As long as "A" is unambiguously a path, index entries for "A", "B" (and everything that follows) are reset to the HEAD revision. * If "A" is unambiguously a rev, on the other hand, the index entries for "B" (and everything that follows) are reset to the "A" revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24tests: do not use implicit "git diff --no-index"Libravatar Junio C Hamano1-6/+6
As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05builtin-reset: avoid forking "update-index --refresh"Libravatar Johannes Schindelin1-0/+10
Instead of forking update-index, call refresh_cache() directly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05builtin-reset: do not call "ls-files --unmerged"Libravatar Johannes Schindelin1-0/+9
Since reset is a builtin now, it can use the full power of libgit.a and check for unmerged entries itself. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-03git-reset: do not be confused if there is nothing to resetLibravatar Johannes Schindelin1-0/+7
The purpose of the function update_index_from_diff() (which is the callback function we give do_diff_cache()) is to update those index entries which differ from the given commit. Since do_diff_cache() plays games with the in-memory index, this function discarded the cache and reread it. Then, back in the function read_from_tree() we wrote the index. Of course, this broke down when there were no changes and update_index_from_diff() was not called, and therefore the mangled index was not discarded. The solution is to move the index writing into the function update_index_from_diff(). Noticed by Björn Steinbrink. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13An additional test for "git-reset -- path"Libravatar Junio C Hamano1-0/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-12Add tests for documented features of "git reset".Libravatar Carlos Rica1-0/+389
This adds the new file t/t7102-reset.sh following the text and examples in "Documentation/git-reset.txt" in order to check the behaviour of the upcoming "builtin-reset.c", and be able to compare it with the original "git-reset.sh". Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>