summaryrefslogtreecommitdiff
path: root/t/t3510-cherry-pick-sequence.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-03-31sequencer: fix edit handling for cherry-pick and revert messagesLibravatar Elijah Newren1-1/+31
save_opts() should save any non-default values. It was intended to do this, but since most options in struct replay_opts default to 0, it only saved non-zero values. Unfortunately, this does not always work for options.edit. Roughly speaking, options.edit had a default value of 0 for cherry-pick but a default value of 1 for revert. Make save_opts() record a value whenever it differs from the default. options.edit was also overly simplistic; we had more than two cases. The behavior that previously existed was as follows: Non-conflict commits Right after Conflict revert Edit iff isatty(0) Edit (ignore isatty(0)) cherry-pick No edit See above Specify --edit Edit (ignore isatty(0)) See above Specify --no-edit (*) See above (*) Before stopping for conflicts, No edit is the behavior. After stopping for conflicts, the --no-edit flag is not saved so see the first two rows. However, the expected behavior is: Non-conflict commits Right after Conflict revert Edit iff isatty(0) Edit iff isatty(0) cherry-pick No edit Edit iff isatty(0) Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0)) Specify --no-edit No edit No edit In order to get the expected behavior, we need to change options.edit to a tri-state: unspecified, false, or true. When specified, we follow what it says. When unspecified, we need to check whether the current commit being created is resolving a conflict as well as consulting options.action and isatty(0). While at it, add a should_edit() utility function that compresses options.edit down to a boolean based on the additional information for the non-conflict case. continue_single_pick() is the function responsible for resuming after conflict cases, regardless of whether there is one commit being picked or many. Make this function stop assuming edit behavior in all cases, so that it can correctly handle !isatty(0) and specific requests to not edit the commit message. Reported-by: Renato Botelho <garga@freebsd.org> Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-10tests: remove most uses of test_i18ncmpLibravatar Ævar Arnfjörð Bjarmason1-4/+4
As a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) remove most uses of test_i18ncmp via a simple s/test_i18ncmp/test_cmp/g search-replacement. I'm leaving t6300-for-each-ref.sh out due to a conflict with in-flight changes between "master" and "seen", as well as the prerequisite itself due to other changes between "master" and "next/seen" which add new test_i18ncmp uses. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-06cherry-pick: add test for `--skip` advice in `git commit`Libravatar Johannes Schindelin1-1/+2
In dcb500dc16c (cherry-pick/revert: advise using --skip, 2019-07-02), `git commit` learned to suggest to run `git cherry-pick --skip` when trying to cherry-pick an empty patch, but that was never tested for. Here is a test that verifies that a message is given to the user that contains the correct invocation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-02cherry-pick/revert: advise using --skipLibravatar Rohit Ashiwal1-0/+20
The previous commit introduced a --skip flag for cherry-pick and revert. Update the advice messages, to tell users about this less cumbersome way of skipping commits. Also add tests to ensure everything is working fine. Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-02cherry-pick/revert: add --skip optionLibravatar Rohit Ashiwal1-0/+102
git am or rebase have a --skip flag to skip the current commit if the user wishes to do so. During a cherry-pick or revert a user could likewise skip a commit, but needs to use 'git reset' (or in the case of conflicts 'git reset --merge'), followed by 'git (cherry-pick | revert) --continue' to skip the commit. This is more annoying and sometimes confusing on the users' part. Add a `--skip` option to make skipping commits easier for the user and to make the commands more consistent. In the next commit, we will change the advice messages hence finishing the process of teaching revert and cherry-pick "how to skip commits". Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-26t3510: stop using '-m 1' to force failure mid-sequence of cherry-picksLibravatar Sergey Organov1-2/+6
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so this method to force failure will stop to work. Use '-m 4' instead as it's very unlikely we will ever have such an octopus in this test setup. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20Merge branch 'nd/cherry-pick-quit-fix'Libravatar Junio C Hamano1-1/+6
"git cherry-pick --quit" failed to remove CHERRY_PICK_HEAD even though we won't be in a cherry-pick session after it returns, which has been corrected. * nd/cherry-pick-quit-fix: cherry-pick: fix --quit not deleting CHERRY_PICK_HEAD
2018-08-16cherry-pick: fix --quit not deleting CHERRY_PICK_HEADLibravatar Nguyễn Thái Ngọc Duy1-1/+6
--quit is supposed to be --abort but without restoring HEAD. Leaving CHERRY_PICK_HEAD behind could make other commands mistake that cherry-pick is still ongoing (e.g. "git commit --amend" will refuse to work). Clean it too. For --abort, this job of deleting CHERRY_PICK_HEAD is on "git reset" so we don't need to do anything else. But let's add extra checks in --abort tests to confirm. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-24Merge branch 'jk/empty-pick-fix'Libravatar Junio C Hamano1-1/+6
Handling of an empty range by "git cherry-pick" was inconsistent depending on how the range ended up to be empty, which has been corrected. * jk/empty-pick-fix: sequencer: don't say BUG on bogus input sequencer: handle empty-set cases consistently
2018-07-11sequencer: handle empty-set cases consistentlyLibravatar Jeff King1-1/+6
If the user gives us a set that prepare_revision_walk() takes to be empty, like: git cherry-pick base..base then we report an error. It's nonsense, and there's nothing to pick. But if they use revision options that later cull the list, like: git cherry-pick --author=nobody base~2..base then we quietly create an empty todo list and return success. Arguably either behavior is acceptable, but we should definitely be consistent about it. Reporting an error seems to match the original intent, which dates all the way back to 7e2bfd3f99 (revert: allow cherry-picking more than one commit, 2010-06-02). That in turn was trying to match the single-commit case that existed before then (and which continues to issue an error). Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t: switch $_x40 to $OID_REGEXLibravatar brian m. carlson1-4/+4
Switch all uses of $_x40 to $OID_REGEX so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_x40/$OID_REGEX/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25Merge branch 'ps/test-chmtime-get'Libravatar Junio C Hamano1-2/+2
Test cleanup. * ps/test-chmtime-get: t/helper: 'test-chmtime (--get|-g)' to print only the mtime
2018-04-09t/helper: 'test-chmtime (--get|-g)' to print only the mtimeLibravatar Paul-Sebastian Ungureanu1-2/+2
Compared to 'test-chmtime -v +0 file' which prints the mtime and and the file name, 'test-chmtime --get file' displays only the mtime. If it is used in combination with (+|=|=+|=-|-)seconds, it changes and prints the new value. test-chmtime -v +0 file | sed 's/[^0-9].*$//' is now equivalent to: test-chmtime --get file Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-27t/helper: merge test-chmtime into test-toolLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-18Merge branch 'pb/test-must-fail-is-for-git'Libravatar Junio C Hamano1-3/+3
Test cleanup. * pb/test-must-fail-is-for-git: t9813: avoid using pipes don't use test_must_fail with grep
2017-01-07don't use test_must_fail with grepLibravatar Pranit Bauva1-3/+3
test_must_fail should only be used for testing git commands. To test the failure of other commands use `!`. Reported-by: Stefan Beller <sbeller@google.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-09sequencer: make sequencer abort saferLibravatar Stephan Beyer1-1/+1
In contrast to "git am --abort", a sequencer abort did not check whether the current HEAD is the one that is expected. This can lead to loss of work (when not spotted and resolved using reflog before the garbage collector chimes in). This behavior is now changed by mimicking "git am --abort". The abortion is done but HEAD is not changed when the current HEAD is not the expected HEAD. A new file "sequencer/abort-safety" is added to save the expected HEAD. The new behavior is only active when --abort is invoked on multiple picks. The problem does not occur for the single-pick case because it is handled differently. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-09t3510: test that cherry-pick --abort does not unsafely change HEADLibravatar Stephan Beyer1-0/+10
Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-22tests: move test_cmp_rev to test-lib-functionsLibravatar Martin von Zweigbergk1-6/+0
A function for checking that two given parameters refer to the same revision was defined in several places, so move the definition to test-lib-functions.sh instead. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14cherry-pick: don't forget -s on failureLibravatar Miklos Vajna1-3/+3
In case 'git cherry-pick -s <commit>' failed, the user had to use 'git commit -s' (i.e. state the -s option again), which is easy to forget about. Instead, write the signed-off-by line early, so plain 'git commit' will have the same result. Also update 'git commit -s', so that in case there is already a relevant Signed-off-by line before the Conflicts: line, it won't add one more at the end of the message. If there is no such line, then add it before the the Conflicts: line. Signed-off-by: Miklos Vajna <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-07Merge branch 'rr/maint-t3510-cascade-fix'Libravatar Junio C Hamano1-1/+1
* rr/maint-t3510-cascade-fix: t3510 (cherry-pick-sequence): add missing '&&'
2012-06-04t3510 (cherry-pick-sequence): add missing '&&'Libravatar Ramkumar Ramachandra1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Fix an instance of this in the setup. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15t3502, t3510: clarify cherry-pick -m failureLibravatar Ramkumar Ramachandra1-1/+1
The "cherry-pick persists opts correctly" test in t3510 (cherry-pick-sequence) can cause some confusion, because the command actually has two points of failure: 1. "-m 1" is specified on the command-line despite the base commit "initial" not being a merge-commit. 2. The revision range indicates that there will be a conflict that needs to be resolved. Although the former error is trapped, and cherry-pick die()s with the exit status 128, the reader may be distracted by the latter. Fix this by changing the revision range to something that wouldn't cause a conflict. Additionally, explicitly check the exit code in "cherry-pick a non-merge with -m should fail" in t3502 (cherry-pick-merge) to reassure the reader that this failure has nothing to do with the sequencer itself. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15t3510 (cherry-pick-sequencer): use exit statusLibravatar Ramkumar Ramachandra1-29/+29
All the tests asserting failure use 'test_must_fail', which simply checks for a non-zero exit status, potentially hiding underlying bugs. So, replace instances of 'test_must_fail' with 'test_expect_code' to check the exit status explicitly, where appropriate. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15revert: tolerate extra spaces, tabs in insn sheetLibravatar Ramkumar Ramachandra1-0/+11
Tolerate extra spaces and tabs as part of the the field separator in '.git/sequencer/todo', for people with fat fingers. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15revert: make commit subjects in insn sheet optionalLibravatar Ramkumar Ramachandra1-0/+28
Change the instruction sheet format subtly so that the subject of the commit message that follows the object name is optional. As a result, an instruction sheet like this is now perfectly valid: pick 35b0426 pick fbd5bbcbc2e pick 7362160f While at it, also fix a bug introduced by 5a5d80f4 (revert: Introduce --continue to continue the operation, 2011-08-04) that failed to read lines that are too long to fit on the commit-id-shaped buffer we currently use; eliminate the need for the buffer altogether. In addition to literal SHA-1 hexes, you can now safely use expressions like the following in the instruction sheet: featurebranch~4 rr/revert-cherry-pick-continue^2~12@{12 days ago} [jc: simplify parsing] Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12Revert "reset: Make reset remove the sequencer state"Libravatar Jonathan Nieder1-1/+1
This reverts commit 95eb88d8ee588d89b4f06d2753ed4d16ab13b39f, which was a UI experiment that did not reflect how "git reset" actually gets used. The reversion also fixes a test, indicated in the patch. Encouraged-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: do not remove state until sequence is finishedLibravatar Jonathan Nieder1-3/+3
As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes the sequencer state just before applying the final patch. In the single-pick case, that was a good thing, since --abort and --continue work fine without access to such state and removing it provides a signal that git should not complain about the need to clobber it ("a cherry-pick or revert is already in progress") in sequences like the following: git cherry-pick foo git read-tree -m -u HEAD; # forget that; let's try a different one git cherry-pick bar After the recent patch "allow single-pick in the middle of cherry-pick sequence" we don't need that hack any more. In the new regime, a traditional "git cherry-pick <commit>" command never looks at .git/sequencer, so we do not need to cripple "git cherry-pick <commit>..<commit>" for it any more. So now you can run "git cherry-pick --abort" near the end of a multi-pick sequence and it will abort the entire sequence, instead of misbehaving and aborting just the final commit. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: allow single-pick in the middle of cherry-pick sequenceLibravatar Jonathan Nieder1-0/+12
After messing up a difficult conflict resolution in the middle of a cherry-pick sequence, it can be useful to be able to git checkout HEAD . && git cherry-pick that-one-commit to restart the conflict resolution. The current code however errors out saying that another cherry-pick is already in progress. Suggested-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: pass around rev-list args in already-parsed formLibravatar Jonathan Nieder1-0/+5
Since 7e2bfd3f (revert: allow cherry-picking more than one commit, 2010-07-02), the pick/revert machinery has kept track of the set of commits to be cherry-picked or reverted using commit_argc and commit_argv variables, storing the corresponding command-line parameters. Future callers as other commands are built in (am, rebase, sequencer) may find it easier to pass rev-list options to this machinery in already-parsed form. Teach cmd_cherry_pick and cmd_revert to parse the rev-list arguments in advance and pass the commit set to pick_revisions() as a rev_info structure. Original patch by Jonathan, tweaks and test from Ram. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Improved-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: allow cherry-pick --continue to commit before resumingLibravatar Jonathan Nieder1-3/+136
When "git cherry-pick ..bar" encounters conflicts, permit the operator to use cherry-pick --continue after resolving them as a shortcut for "git commit && git cherry-pick --continue" to record the resolution and carry on with the rest of the sequence. This improves the analogy with "git rebase" (in olden days --continue was the way to preserve authorship when a rebase encountered conflicts) and fits well with a general UI goal of making "git cmd --continue" save humans the trouble of deciding what to do next. Example: after encountering a conflict from running "git cherry-pick foo bar baz": CONFLICT (content): Merge conflict in main.c error: could not apply f78a8d98c... bar! hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' We edit main.c to resolve the conflict, mark it acceptable with "git add main.c", and can run "cherry-pick --continue" to resume the sequence. $ git cherry-pick --continue [editor opens to confirm commit message] [master 78c8a8c98] bar! 1 files changed, 1 insertions(+), 1 deletions(-) [master 87ca8798c] baz! 1 files changed, 1 insertions(+), 1 deletions(-) This is done for both codepaths to pick multiple commits and a single commit. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: remove --reset compatibility optionLibravatar Jonathan Nieder1-2/+2
Remove the "git cherry-pick --reset" option, which has a different preferred spelling nowadays ("--quit"). Luckily the old --reset name was not around long enough for anyone to get used to it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: introduce --abort to cancel a failed cherry-pickLibravatar Jonathan Nieder1-0/+96
After running some ill-advised command like "git cherry-pick HEAD..linux-next", the bewildered novice may want to return to more familiar territory. Introduce a "git cherry-pick --abort" command that rolls back the entire cherry-pick sequence and places the repository back on solid ground. Just like "git merge --abort", this internally uses "git reset --merge", so local changes not involved in the conflict resolution are preserved. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: rename --reset option to --quitLibravatar Jonathan Nieder1-5/+26
The option to "git cherry-pick" and "git revert" to discard the sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce --reset to remove sequencer state, 2011-08-04) has a confusing name. Change it now, while we still have the time. The new name for "cherry-pick, please get out of my way, since I've long forgotten about the sequence of commits I was cherry-picking when you wrote that old .git/sequencer directory" is --quit. Mnemonic: this is analagous to quiting a program the user is no longer using --- we just want to get out of the multiple-command cherry-pick procedure and not to reset HEAD or rewind any other old state. The "--reset" option is kept as a synonym to minimize the impact. We might consider dropping it for simplicity in a separate patch, though. Adjust documentation and tests to use the newly preferred name (--quit) instead of --reset. While at it, let's clarify the short descriptions of these operations in "-h" output. Before: --reset forget the current operation --continue continue the current operation After: --quit end revert or cherry-pick sequence --continue resume revert or cherry-pick sequence Noticed-by: Phil Hord <phil.hord@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08revert: Introduce --continue to continue the operationLibravatar Ramkumar Ramachandra1-0/+96
Introduce a new "git cherry-pick --continue" command which uses the information in ".git/sequencer" to continue a cherry-pick that stopped because of a conflict or other error. It works by dropping the first instruction from .git/sequencer/todo and performing the remaining cherry-picks listed there, with options (think "-s" and "-X") from the initial command listed in ".git/sequencer/opts". So now you can do: $ git cherry-pick -Xpatience foo..bar ... description conflict in commit moo ... $ git cherry-pick --continue error: 'cherry-pick' is not possible because you have unmerged files. fatal: failed to resume cherry-pick $ echo resolved >conflictingfile $ git add conflictingfile && git commit $ git cherry-pick --continue; # resumes with the commit after "moo" During the "git commit" stage, CHERRY_PICK_HEAD will aid by providing the commit message from the conflicting "moo" commit. Note that the cherry-pick mechanism has no control at this stage, so the user is free to violate anything that was specified during the first cherry-pick invocation. For example, if "-x" was specified during the first cherry-pick invocation, the user is free to edit out the message during commit time. Note that the "--signoff" option specified at cherry-pick invocation time is not reflected in the commit message provided by CHERRY_PICK_HEAD; the user must take care to add "--signoff" during the "git commit" invocation. Helped-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08revert: Don't implicitly stomp pending sequencer operationLibravatar Ramkumar Ramachandra1-0/+9
Protect the user from forgetting about a pending sequencer operation by immediately erroring out when an existing cherry-pick or revert operation is in progress like: $ git cherry-pick foo ... conflict ... $ git cherry-pick moo error: .git/sequencer already exists hint: A cherry-pick or revert is in progress hint: Use --reset to forget about it fatal: cherry-pick failed A naive version of this would break the following established ways of working: $ git cherry-pick foo ... conflict ... $ git reset --hard # I actually meant "moo" when I said "foo" $ git cherry-pick moo $ git cherry-pick foo ... conflict ... $ git commit # commit the resolution $ git cherry-pick moo # New operation However, the previous patches "reset: Make reset remove the sequencer state" and "revert: Remove sequencer state when no commits are pending" make sure that this does not happen. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08revert: Remove sequencer state when no commits are pendingLibravatar Ramkumar Ramachandra1-0/+24
When cherry-pick or revert is called on a list of commits, and a conflict encountered somewhere in the middle, the data in ".git/sequencer" is required to continue the operation. However, when a conflict is encountered in the very last commit, the user will have to "continue" after resolving the conflict and committing just so that the sequencer state is removed. This is how the current "rebase -i" script works as well. $ git cherry-pick foo..bar ... conflict encountered while picking "bar" ... $ echo "resolved" >problematicfile $ git add problematicfile $ git commit $ git cherry-pick --continue # This would be a no-op Change this so that the sequencer state is cleared when a conflict is encountered in the last commit. Incidentally, this patch makes sure that some existing tests don't break when features like "--reset" and "--continue" are implemented later in the series. A better way to implement this feature is to get the last "git commit" to remove the sequencer state. However, that requires tighter coupling between "git commit" and the sequencer, a goal that can be pursued once the sequencer is made more general. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04revert: Introduce --reset to remove sequencer stateLibravatar Ramkumar Ramachandra1-1/+13
To explicitly remove the sequencer state for a fresh cherry-pick or revert invocation, introduce a new subcommand called "--reset" to remove the sequencer state. Take the opportunity to publicly expose the sequencer paths, and a generic function called "remove_sequencer_state" that various git programs can use to remove the sequencer state in a uniform manner; "git reset" uses it later in this series. Introducing this public API is also in line with our long-term goal of eventually factoring out functions from revert.c into a generic commit sequencer. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04revert: Save command-line options for continuing operationLibravatar Ramkumar Ramachandra1-2/+27
In the same spirit as ".git/sequencer/head" and ".git/sequencer/todo", introduce ".git/sequencer/opts" to persist the replay_opts structure for continuing after a conflict resolution. Use the gitconfig format for this file so that it looks like: [options] signoff = true record-origin = true mainline = 1 strategy = recursive strategy-option = patience strategy-option = ours Helped-by: Jonathan Nieder <jrnieder@gmail.com> Helped-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04revert: Save data for continuing after conflict resolutionLibravatar Ramkumar Ramachandra1-0/+48
Ever since v1.7.2-rc1~4^2~7 (revert: allow cherry-picking more than one commit, 2010-06-02), a single invocation of "git cherry-pick" or "git revert" can perform picks of several individual commits. To implement features like "--continue" to continue the whole operation, we will need to store some information about the state and the plan at the beginning. Introduce a ".git/sequencer/head" file to store this state, and ".git/sequencer/todo" file to store the plan. The head file contains the SHA-1 of the HEAD before the start of the operation, and the todo file contains an instruction sheet whose format is inspired by the format of the "rebase -i" instruction sheet. As a result, a typical todo file looks like: pick 8537f0e submodule add: test failure when url is not configured pick 4d68932 submodule add: allow relative repository path pick f22a17e submodule add: clean up duplicated code pick 59a5775 make copy_ref globally available Since SHA-1 hex is abbreviated using an find_unique_abbrev(), it is unambiguous. This does not guarantee that there will be no ambiguity when more objects are added to the repository. These two files alone are not enough to implement a "--continue" that remembers the command-line options specified; later patches in the series save them too. These new files are unrelated to the existing .git/CHERRY_PICK_HEAD, which will still be useful while committing after a conflict resolution. Inspired-by: Christian Couder <chriscool@tuxfamily.org> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>