summaryrefslogtreecommitdiff
path: root/builtin/revert.c
AgeCommit message (Collapse)AuthorFilesLines
2011-12-12revert: stop creating and removing sequencer-old directoryLibravatar Jonathan Nieder1-3/+3
Now that "git reset" no longer implicitly removes .git/sequencer that the operator may or may not have wanted to keep, the logic to write a backup copy of .git/sequencer and remove it when stale is not needed any more. Simplify the sequencer API and repository layout by dropping it. 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-11/+1
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/+26
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-24/+29
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/+20
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-12-12revert: give --continue handling its own functionLibravatar Jonathan Nieder1-11/+17
This makes pick_revisions() a little shorter and easier to read straight through. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-23revert --abort: do not leave behind useless sequencer-old directoryLibravatar Jonathan Nieder1-0/+1
The "git cherry-pick --abort" command currently renames the .git/sequencer directory to .git/sequencer-old instead of removing it on success due to an accident. cherry-pick --abort is designed to work in three steps: 1) find which commit to roll back to 2) call "git reset --merge <commit>" to move to that commit 3) remove the .git/sequencer directory But the careless author forgot step 3 entirely. The only reason the command worked anyway is that "git reset --merge <commit>" renames the .git/sequencer directory as a secondary effect --- after moving to <commit>, or so the logic goes, it is unlikely but possible that the caller of git reset wants to continue the series of cherry-picks that was in progress, so git renames the sequencer state to .git/sequencer-old to be helpful while allowing the cherry-pick to be resumed if the caller did not want to end the sequence after all. By running "git cherry-pick --abort", the operator has clearly indicated that she is not planning to continue cherry-picking. Remove the (renamed) .git/sequencer directory as intended all along. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-23Fix revert --abort on WindowsLibravatar Johannes Sixt1-2/+2
On Windows, it is not possible to rename or remove a directory that has open files. 'revert --abort' renamed .git/sequencer when it still had .git/sequencer/head open. Close the file as early as possible to allow the rename operation on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-23revert: do not pass non-literal string as format to git_path()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
This fixes the following warning. CC builtin/revert.o builtin/revert.c: In function ‘write_cherry_pick_head’: builtin/revert.c:311: warning: format not a string literal and no format arguments Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: remove --reset compatibility optionLibravatar Jonathan Nieder1-3/+0
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-3/+84
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: write REVERT_HEAD pseudoref during conflicted revertLibravatar Jonathan Nieder1-3/+5
When conflicts are encountered while reverting a commit, it can be handy to have the name of that commit easily available. For example, to produce a copy of the patch to refer to while resolving conflicts: $ git revert 2eceb2a8 error: could not revert 2eceb2a8... awesome, buggy feature $ git show -R REVERT_HEAD >the-patch $ edit $(git diff --name-only) Set a REVERT_HEAD pseudoref when "git revert" does not make a commit, for cases like this. This also makes it possible for scripts to distinguish between a revert that encountered conflicts and other sources of an unmerged index. After successfully committing, resetting with "git reset", or moving to another commit with "git checkout" or "git reset", the pseudoref is no longer useful, so remove it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: improve error message for cherry-pick during cherry-pickLibravatar Jonathan Nieder1-7/+6
In the spirit of v1.6.3.3~3^2 (refuse to merge during a merge, 2009-07-01), "git cherry-pick" refuses to start a new cherry-pick when in the middle of an existing conflicted cherry-pick in the following sequence: 1. git cherry-pick HEAD..origin 2. resolve conflicts 3. git cherry-pick HEAD..origin (instead of "git cherry-pick --continue", by mistake) Good. However, the error message on attempting step 3 is more convoluted than necessary: $ git cherry-pick HEAD..origin error: .git/sequencer already exists. error: A cherry-pick or revert is in progress. hint: Use --continue to continue the operation hint: or --quit to forget about it fatal: cherry-pick failed Clarify by removing the redundant first "error:" message, simplifying the advice, and using lower-case and no full stops to be consistent with other commands that prefix their messages with "error:", so it becomes error: a cherry-pick or revert is already in progress hint: try "git cherry-pick (--continue | --quit)" fatal: cherry-pick failed The "fatal: cherry-pick failed" line seems unnecessary, too, but that can be fixed some other day. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: rearrange pick_revisions() for clarityLibravatar Jonathan Nieder1-24/+24
Deal completely with "cherry-pick --quit" and --continue at the beginning of pick_revisions(), leaving the rest of the function for the more interesting "git cherry-pick <commits>" case. No functional change intended. The impact is just to unindent the code a little. 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-11/+14
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-11-17do not let git_path clobber errno when reporting errorsLibravatar Jonathan Nieder1-4/+5
Because git_path() calls vsnprintf(), code like fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666); die_errno(_("Could not write to '%s'"), git_path("SQUASH_MSG")); can end up printing an error indicator from vsnprintf() instead of open() by mistake. Store the path we are trying to write to in a temporary variable and pass _that_ to die_errno(), so the messages written by git cherry-pick/revert and git merge can avoid this source of confusion. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-15revert: prettify fatal messagesLibravatar Ramkumar Ramachandra1-5/+5
Some of the fatal messages printed by revert and cherry-pick look ugly like the following: fatal: Could not open .git/sequencer/todo.: No such file or directory The culprit here is that these callers of the die_errno() function did not take it into account that the message string they give to it is followed by ": <strerror>", hence the message typically should not end with the full-stop. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-19Merge branch 'js/no-cherry-pick-head-after-punted'Libravatar Junio C Hamano1-7/+16
* js/no-cherry-pick-head-after-punted: cherry-pick: do not give irrelevant advice when cherry-pick punted revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
2011-10-12Merge branch 'jc/parse-options-boolean'Libravatar Junio C Hamano1-3/+1
* jc/parse-options-boolean: apply: use OPT_NOOP_NOARG revert: use OPT_NOOP_NOARG parseopt: add OPT_NOOP_NOARG archive.c: use OPT_BOOL() parse-options: deprecate OPT_BOOLEAN Conflicts: builtin/revert.c
2011-10-09Fix some "variable might be used uninitialized" warningsLibravatar Ramsay Jones1-1/+1
In particular, gcc complains as follows: CC tree-walk.o tree-walk.c: In function `traverse_trees': tree-walk.c:347: warning: 'e' might be used uninitialized in this \ function CC builtin/revert.o builtin/revert.c: In function `verify_opt_mutually_compatible': builtin/revert.c:113: warning: 'opt2' might be used uninitialized in \ this function Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06Merge branch 'js/maint-no-cherry-pick-head-after-punted' into ↵Libravatar Junio C Hamano1-7/+16
js/no-cherry-pick-head-after-punted * js/maint-no-cherry-pick-head-after-punted: cherry-pick: do not give irrelevant advice when cherry-pick punted revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so Conflicts: builtin/revert.c
2011-10-06cherry-pick: do not give irrelevant advice when cherry-pick puntedLibravatar Jay Soffian1-5/+7
If a cherry-pick did not even start because the working tree had local changes that would overlap with the operation, we shouldn't be advising the users to resolve conflicts nor to conclude it with "git commit". Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do soLibravatar Jay Soffian1-2/+9
do_pick_commit() writes out CHERRY_PICK_HEAD before invoking merge (either via do_recursive_merge() or try_merge_command()) on the assumption that if the merge fails it is due to conflict. However, if the tree is dirty, the merge may not even start, aborting before do_pick_commit() can remove CHERRY_PICK_HEAD. Instead, defer writing CHERRY_PICK_HEAD till after merge has returned. At this point we know the merge has either succeeded or failed due to conflict. In either case, we want CHERRY_PICK_HEAD to be written so that it may be picked up by the subsequent invocation of commit. Note that do_recursive_merge() aborts if the merge cannot start, while try_merge_command() returns a non-zero value other than 1. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'rr/revert-cherry-pick-continue'Libravatar Junio C Hamano1-154/+583
* rr/revert-cherry-pick-continue: builtin/revert.c: make commit_list_append() static revert: Propagate errors upwards from do_pick_commit revert: Introduce --continue to continue the operation revert: Don't implicitly stomp pending sequencer operation revert: Remove sequencer state when no commits are pending reset: Make reset remove the sequencer state revert: Introduce --reset to remove sequencer state revert: Make pick_commits functionally act on a commit list revert: Save command-line options for continuing operation revert: Save data for continuing after conflict resolution revert: Don't create invalid replay_opts in parse_args revert: Separate cmdline parsing from functional code revert: Introduce struct to keep command-line options revert: Eliminate global "commit" variable revert: Rename no_replay to record_origin revert: Don't check lone argument in get_encoding revert: Simplify and inline add_message_to_msg config: Introduce functions to write non-standard file advice: Introduce error_resolve_conflict
2011-09-28revert: use OPT_NOOP_NOARGLibravatar René Scharfe1-3/+1
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11builtin/revert.c: make commit_list_append() staticLibravatar Junio C Hamano1-2/+2
There is nobody outside that calls into this helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-25Merge branch 'jn/plug-empty-tree-leak'Libravatar Junio C Hamano1-6/+1
* jn/plug-empty-tree-leak: merge-recursive: take advantage of hardcoded empty tree revert: plug memory leak in "cherry-pick root commit" codepath
2011-08-16revert: plug memory leak in "cherry-pick root commit" codepathLibravatar Jonathan Nieder1-6/+1
The empty tree passed as common ancestor to merge_trees() when cherry-picking a parentless commit is allocated on the heap and never freed. Leaking such a small one-time allocation is not a very big problem, but now that "git cherry-pick" can cherry-pick multiple commits it can start to add up. Avoid the leak by storing the fake tree exactly once in the BSS section (i.e., use a static). While at it, let's add a test to make sure cherry-picking multiple parentless commits continues to work. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08revert: Propagate errors upwards from do_pick_commitLibravatar Ramkumar Ramachandra1-46/+40
Currently, revert_or_cherry_pick can fail in two ways. If it encounters a conflict, it returns a positive number indicating the intended exit status for the git wrapper to pass on; for all other errors, it calls die(). The latter behavior is inconsiderate towards callers, as it denies them the opportunity to recover from errors and do other things. After this patch, revert_or_cherry_pick will still return a positive return value to indicate an exit status for conflicts as before, while for some other errors, it will print an error message and return -1 instead of die()-ing. The cmd_revert and cmd_cherry_pick are adjusted to handle the fatal errors by die()-ing themselves. While the full benefits of this patch will only be seen once all the "die" calls are replaced with calls to "error", its immediate impact is to change some "fatal:" messages to say "error:" and to add a new "fatal: cherry-pick failed" message at the end when the operation fails. Inspired-by: Christian Couder <chriscool@tuxfamily.org> Mentored-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: 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-4/+184
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-5/+25
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-1/+11
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-19/+43
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: Make pick_commits functionally act on a commit listLibravatar Ramkumar Ramachandra1-15/+28
Apart from its central objective of calling into the picking mechanism, pick_commits creates a sequencer directory, prepares a todo list, and even acts upon the "--reset" subcommand. This makes for a bad API since the central worry of callers is to figure out whether or not any conflicts were encountered during the cherry picking. The current API is like: if (pick_commits(opts) < 0) print "Something failed, we're not sure what" So, change pick_commits so that it's only responsible for picking commits in a loop and reporting any errors, leaving the rest to a new function called pick_revisions. Consequently, the API of pick_commits becomes much clearer: act_on_subcommand(opts->subcommand); todo_list = prepare_todo_list(); if (pick_commits(todo_list, opts) < 0) print "Error encountered while picking commits" Now, callers can easily call-in to the cherry-picking machinery by constructing an arbitrary todo list along with some options. 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-0/+33
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-4/+130
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>
2011-08-04revert: Don't create invalid replay_opts in parse_argsLibravatar Ramkumar Ramachandra1-11/+27
The "--ff" command-line option cannot be used with some other command-line options. However, parse_args still parses these incompatible options into a replay_opts structure for use by the rest of the program. Although pick_commits, the current gatekeeper to the cherry-pick machinery, checks the validity of the replay_opts structure before before starting its operation, there will be multiple entry points to the cherry-pick machinery in future. To futureproof the code and catch these errors in one place, make sure that an invalid replay_opts structure is not created by parse_args in the first place. We still check the replay_opts structure for validity in pick_commits, but this is an assert() now to emphasize that it's the caller's responsibility to get it right. Inspired-by: Christian Couder <chriscool@tuxfamily.org> Mentored-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: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04revert: Separate cmdline parsing from functional codeLibravatar Ramkumar Ramachandra1-7/+7
Currently, revert_or_cherry_pick sets up a default git config, parses command-line arguments, before preparing to pick commits. This makes for a bad API as the central worry of callers is to assert whether or not a conflict occured while cherry picking. The current API is like: if (revert_or_cherry_pick(argc, argv, opts) < 0) print "Something failed, we're not sure what" Simplify and rename revert_or_cherry_pick to pick_commits so that it only has the responsibility of setting up the revision walker and picking commits in a loop. Transfer the remaining work to its callers. Now, the API is simplified as: if (parse_args(argc, argv, opts) < 0) print "Can't parse arguments" if (pick_commits(opts) < 0) print "Error encountered in picking machinery" Later in the series, pick_commits will also serve as the starting point for continuing a cherry-pick or revert. Inspired-by: Christian Couder <chriscool@tuxfamily.org> 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>
2011-08-04revert: Introduce struct to keep command-line optionsLibravatar Ramkumar Ramachandra1-88/+113
The current code uses a set of file-scope static variables to tell the cherry-pick/ revert machinery how to replay the changes, and initializes them by parsing the command-line arguments. In later steps in this series, we would like to introduce an API function that calls into this machinery directly and have a way to tell it what to do. Hence, introduce a structure to group these variables, so that the API can take them as a single replay_options parameter. The only exception is the variable "me" -- remove it since it not an independent option, and can be inferred from the action. Unfortunately, this patch introduces a minor regression. Parsing strategy-option violates a C89 rule: Initializers cannot refer to variables whose address is not known at compile time. Currently, this rule is violated by some other parts of Git as well, and it is possible to get GCC to report these instances using the "-std=c89 -pedantic" option. Inspired-by: Christian Couder <chriscool@tuxfamily.org> Mentored-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: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04revert: Eliminate global "commit" variableLibravatar Ramkumar Ramachandra1-11/+11
Functions which act on commits currently rely on a file-scope static variable to be set before they're called. Consequently, the API and corresponding callsites are ugly and unclear. Remove this variable and change their API to accept the commit to act on as additional argument so that the callsites change from looking like commit = prepare_a_commit(); act_on_commit(); to looking like commit = prepare_a_commit(); act_on_commit(commit); This change is also in line with our long-term goal of exposing some of these functions through a public API. Inspired-by: Christian Couder <chriscool@tuxfamily.org> Helped-by: Junio C Hamano <gitster@pobox.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>
2011-08-04revert: Rename no_replay to record_originLibravatar Ramkumar Ramachandra1-4/+4
The "-x" command-line option is used to record the name of the original commits being picked in the commit message. The variable corresponding to this option is named "no_replay" for historical reasons; the name is especially confusing because the term "replay" is used to describe what cherry-pick does (for example, in the documentation of the "--mainline" option). So, give the variable corresponding to the "-x" command-line option a better name: "record_origin". Mentored-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04revert: Don't check lone argument in get_encodingLibravatar Ramkumar Ramachandra1-3/+0
The only place get_encoding uses the global "commit" variable is when writing an error message explaining that its lone argument was NULL. Since the function's only caller ensures that a NULL argument isn't passed, we can remove this check with two beneficial consequences: 1. Since the function doesn't use the global "commit" variable any more, it won't need to change when we eliminate the global variable later in the series. 2. Translators no longer need to localize an error message that will never be shown. Suggested-by: Junio C Hamano <gitster@pobox.com> Mentored-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04revert: Simplify and inline add_message_to_msgLibravatar Ramkumar Ramachandra1-14/+14
The add_message_to_msg function has some dead code, an unclear API, only one callsite. While it originally intended fill up an empty commit message with the commit object name while picking, it really doesn't do this -- a bug introduced in v1.5.1-rc1~65^2~2 (Make git-revert & git-cherry-pick a builtin, 2007-03-01). Today, tests in t3505-cherry-pick-empty.sh indicate that not filling up an empty commit message is the desired behavior. Re-implement and inline the function accordingly, with a beneficial side-effect: don't dereference a NULL pointer when the commit doesn't have a delimeter after the header. Helped-by: Junio C Hamano <gitster@pobox.com> Mentored-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04advice: Introduce error_resolve_conflictLibravatar Ramkumar Ramachandra1-9/+0
Enable future callers to report a conflict and not die immediately by introducing a new function called error_resolve_conflict. Re-implement die_resolve_conflict as a call to error_resolve_conflict followed by a call to die. Consequently, the message printed by die_resolve_conflict changes from fatal: 'commit' is not possible because you have unmerged files. Please, fix them up in the work tree ... ... to error: 'commit' is not possible because you have unmerged files. hint: Fix them up in the work tree ... hint: ... fatal: Exiting because of an unresolved conflict. Hints are printed using the same advise function introduced in v1.7.3-rc0~26^2~3 (Introduce advise() to print hints, 2010-08-11). Inspired-by: Christian Couder <chistian.couder@gmail.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> 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-05-16revert: allow reverting a root commitLibravatar Jeff King1-3/+1
Although it is probably an uncommon operation, there is no reason to disallow it, as it works just fine. It is the reverse of a cherry-pick of a root commit, which is already allowed. We do have to tweak one check on whether we have a merge commit, which assumed we had at least one parent. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13revert: Hide '-r' option in default usageLibravatar Ramkumar Ramachandra1-1/+2
The '-r' command-line option is a no-op provided only for backward compatiblity since abd6970 (cherry-pick: make -r the default, 2006-10-05), and somehow ended up surviving across reimplementation in C at 9509af6 (Make git-revert & git-cherry-pick a builtin, 2007-03-01) and another rewrite of the command line parser at f810379 (Make builtin-revert.c use parse_options, 2007-10-07). We should have stopped advertising the option long time ago. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01Merge branch 'ab/i18n-st'Libravatar Junio C Hamano1-30/+42
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
2011-03-09i18n: git-revert split up "could not revert/apply" messageLibravatar Ævar Arnfjörð Bjarmason1-2/+3
Split up the "could not %s %s... %s" message into "could not revert %s... %s" and "could not apply %s... %s". This makes it easier for translators to understand the message. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-revert literal "me" messagesLibravatar Ævar Arnfjörð Bjarmason1-2/+5
Translate messages that use the `me' variable. These are all error messages referencing the command name, so the name shouldn't be translated. 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>
2011-03-09i18n: git-revert "Your local changes" messageLibravatar Ævar Arnfjörð Bjarmason1-5/+13
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>