summaryrefslogtreecommitdiff
path: root/t/t3501-revert-cherry-pick.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-01-19Tighten and correct a few testcases for merging and cherry-pickingLibravatar Elijah Newren1-2/+5
t3501 had a testcase originally added in 05f2dfb965 (cherry-pick: demonstrate a segmentation fault, 2016-11-26) to ensure cherry-pick wouldn't segfault when working with a dirty file involved in a rename. While the segfault was fixed, there was another problem this test demonstrated: namely, that git would overwrite a dirty file involved in a rename. Further, the test encoded a "successful merge" and overwriting of this file as correct behavior. Modify the test so that it would still catch the segfault, but to require the correct behavior. Mark it as test_expect_failure for now too, since this second bug is not yet fixed. t7607 had a test added in 30fd3a5425 (merge overwrites unstaged changes in renamed file, 2012-04-15) specific to looking for a merge overwriting a dirty file involved in a rename, but it too actually encoded what I would term incorrect behavior: it expected the merge to succeed. Fix that, and add a few more checks to make sure that the merge really does produce the expected results. Reviewed-By: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-19Merge branch 'jc/renormalize-merge-kill-safer-crlf'Libravatar Junio C Hamano1-0/+12
Fix a corner case in merge-recursive regression that crept in during 2.10 development cycle. * jc/renormalize-merge-kill-safer-crlf: convert: git cherry-pick -Xrenormalize did not work merge-recursive: handle NULL in add_cacheinfo() correctly cherry-pick: demonstrate a segmentation fault
2016-11-28merge-recursive: handle NULL in add_cacheinfo() correctlyLibravatar Johannes Schindelin1-1/+1
1335d76e45 ("merge: avoid "safer crlf" during recording of merge results", 2016-07-08) tried to split make_cache_entry() call made with CE_MATCH_REFRESH into a call to make_cache_entry() without one, followed by a call to add_cache_entry(), refresh_cache() and another add_cache_entry() as needed. However the conversion was botched in that it forgot that refresh_cache() can return NULL, which was handled correctly in make_cache_entry() but in the updated code. This fixes https://github.com/git-for-windows/git/issues/952 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-28cherry-pick: demonstrate a segmentation faultLibravatar Johannes Schindelin1-0/+12
In https://github.com/git-for-windows/git/issues/952, a complicated scenario was described that leads to a segmentation fault in cherry-pick. It boils down to a certain code path involving a renamed file that is dirty, for which `refresh_cache_entry()` returns `NULL`, and that `NULL` not being handled properly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21sequencer: start error messages consistently with lower caseLibravatar Johannes Schindelin1-1/+1
Quite a few error messages touched by this developer during the work to speed up rebase -i started with an upper case letter, violating our current conventions. Instead of sneaking in this fix (and forgetting quite a few error messages), let's just have one wholesale patch fixing all of the error messages in the sequencer. While at it, the funny "error: Error wrapping up..." was changed to a less funny, but more helpful, "error: failed to finalize...". Pointed out by Junio Hamano. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23Merge branch 'hu/cherry-pick-previous-branch'Libravatar Junio C Hamano1-0/+12
"git cherry-pick" without further options would segfault. Could use a follow-up to handle '-' after argv[1] better. * hu/cherry-pick-previous-branch: cherry-pick: handle "-" after parsing options
2013-10-10cherry-pick: handle "-" after parsing optionsLibravatar Jeff King1-0/+12
Currently, we only try converting argv[1] from "-" into "@{-1}". This means we do not notice "-" when used together with an option. Worse, when "git cherry-pick" is run with no options, we segfault. Fix this by doing the substitution after we have checked that there is something in argv to cherry-pick and know any remaining options are meant for the revision-listing machinery. This still does not handle "-" after the first non-cherry-pick option. For example, git cherry-pick foo~2 - bar~5 and git cherry-pick --no-merges - will still dump usage. Reported-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-20Merge branch 'hu/cherry-pick-previous-branch'Libravatar Junio C Hamano1-0/+20
Just like "git checkout -" knows to check out and "git merge -" knows to merge the branch you were previously on, "git cherry-pick" now understands "git cherry-pick -" to pick from the previous branch. * hu/cherry-pick-previous-branch: cherry-pick: allow "-" as abbreviation of '@{-1}'
2013-09-09cherry-pick: allow "-" as abbreviation of '@{-1}'Libravatar Hiroshige Umino1-0/+20
"-" abbreviation is handy for "cherry-pick" like "checkout" and "merge". It's also good for uniformity that a "-" stands as the name of the previous branch where a branch name is accepted and it could not mean any other things like stdin. Signed-off-by: Hiroshige Umino <hiroshige88@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-05typofix: cherry is spelled with two arsLibravatar Junio C Hamano1-1/+1
Do not say chery; it is spelled cherry. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-23learn to pick/revert into unborn branchLibravatar Martin von Zweigbergk1-0/+9
cherry-picking into an unborn branch should work, so make it work, with or without --ff. Cherry-picking anything other than a commit that only adds files, will naturally result in conflicts. Similarly, revert also works, but will result in conflicts unless the specified revision only deletes files. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on parseoptLibravatar Jiang Xin1-2/+2
Use the i18n-specific test functions in test scripts for parseopt tests. This issue was was introduced in v1.7.10.1-488-g54e6d: 54e6d i18n: parseopt: lookup help and argument translations when showing usage and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-revert "Your local changes" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Translate the "Your local changes [...]" message without using the `me' variable, instead split up the two messages so translators can translate the whole messages as-is. Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-10cherry-pick/revert: transparently refresh indexLibravatar Jonathan Nieder1-0/+10
A stat-dirty index is not a detail that ought to concern the operator of porcelain such as "git cherry-pick". Without this change, a cherry-pick after copying a worktree with rsync errors out with a misleading message. $ git cherry-pick build/top error: Your local changes to 'file.h' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Noticed-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'cc/cherry-pick-stdin'Libravatar Junio C Hamano1-0/+18
* cc/cherry-pick-stdin: revert: do not rebuild argv on heap revert: accept arbitrary rev-list options t3508 (cherry-pick): futureproof against unmerged files
2010-06-29revert: do not rebuild argv on heapLibravatar Jonathan Nieder1-0/+18
Set options in struct rev_info directly so we can reuse the arguments collected from parse_options without modification. This is just a cleanup; no noticeable change is intended. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-13commit: use value of GIT_REFLOG_ACTION env variable as reflog messageLibravatar Christian Couder1-2/+4
The environment variable GIT_REFLOG_ACTION was used by git-commit.sh, but when it was converted to a builtin (f5bbc3225c4b073a7ff3218164a0c820299bc9c6, Port git commit to C, Nov 8 2007) this was lost. Let's use it again as it is more user friendly when reverting or cherry-picking to see "revert" or "cherry-pick" in the reflog rather than to just see "commit". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12Be more user-friendly when refusing to do something because of conflict.Libravatar Matthieu Moy1-1/+1
Various commands refuse to run in the presence of conflicts (commit, merge, pull, cherry-pick/revert). They all used to provide rough, and inconsistant error messages. A new variable advice.resolveconflict is introduced, and allows more verbose messages, pointing the user to the appropriate solution. For commit, the error message used to look like this: $ git commit foo.txt: needs merge foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169) foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030) foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4) error: Error building trees The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN option to make the output more consistant with the other porcelain commands, and catch the error in return, to stop with a clean error message. The next lines were displayed by a call to cache_tree_update(), which is not reached anymore if we noticed the conflict. The new output looks like: U foo.txt fatal: 'commit' is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm <file>' as appropriate to mark resolution and make a commit, or use 'git commit -a'. Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD exists instead of waiting for merge to complain. The behavior of merge and the test-case are slightly modified to reflect the usual flow: start with conflicts, fix them, and afterwards get rid of MERGE_HEAD, with different error messages at each stage. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-15t3501: check that commits are actually doneLibravatar Stephan Beyer1-0/+2
The basic idea of t3501 is to check whether revert and cherry-pick works on renamed files. But as there is no pure cherry-pick/revert test, it is good to also check if commits are actually done in that scenario. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-02revert: actually check for a dirty indexLibravatar Jeff King1-0/+9
The previous code mistakenly used wt_status_prepare to check whether the index had anything commitable in it; however, that function is just an init function, and will never report a dirty index. The correct way with wt_status_* would be to call wt_status_print with the output pointing to /dev/null or similar. However, that does extra work by both examining the working tree and spewing status information to nowhere. Instead, let's just implement the useful subset of wt_status_print as an "is_index_dirty" function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites.Libravatar Kristian Høgsberg1-2/+2
They are already set and exoprted by sourcing ./test-lib.sh in all test scripts. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-01-14Use merge-recursive in git-revert/git-cherry-pickLibravatar Junio C Hamano1-0/+62
This makes revert and cherry-pick to use merge-recursive, to allow them to notice renames. A pair of test scripts demonstrate that an old change before a rename happened can be applied (reverted) after a rename with cherry-pick (with revert). Signed-off-by: Junio C Hamano <junkio@cox.net>