summaryrefslogtreecommitdiff
path: root/t/t3501-revert-cherry-pick.sh
AgeCommit message (Collapse)AuthorFilesLines
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>