2011-08-04 18:39:11 +08:00
|
|
|
#include "cache.h"
|
2017-06-15 02:07:36 +08:00
|
|
|
#include "config.h"
|
2014-10-01 18:28:42 +08:00
|
|
|
#include "lockfile.h"
|
2011-08-04 18:39:11 +08:00
|
|
|
#include "dir.h"
|
2018-05-16 07:42:15 +08:00
|
|
|
#include "object-store.h"
|
2012-01-12 02:15:57 +08:00
|
|
|
#include "object.h"
|
|
|
|
|
#include "commit.h"
|
2017-11-17 19:34:47 +08:00
|
|
|
#include "sequencer.h"
|
2012-01-12 02:15:57 +08:00
|
|
|
#include "tag.h"
|
|
|
|
|
#include "run-command.h"
|
2018-04-11 05:26:18 +08:00
|
|
|
#include "exec-cmd.h"
|
2012-01-12 02:15:57 +08:00
|
|
|
#include "utf8.h"
|
|
|
|
|
#include "cache-tree.h"
|
|
|
|
|
#include "diff.h"
|
|
|
|
|
#include "revision.h"
|
|
|
|
|
#include "rerere.h"
|
|
|
|
|
#include "merge-recursive.h"
|
|
|
|
|
#include "refs.h"
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
#include "argv-array.h"
|
2016-10-21 20:25:12 +08:00
|
|
|
#include "quote.h"
|
2016-11-03 01:29:20 +08:00
|
|
|
#include "trailer.h"
|
2017-01-02 23:26:43 +08:00
|
|
|
#include "log-tree.h"
|
2017-01-02 23:26:47 +08:00
|
|
|
#include "wt-status.h"
|
2017-07-14 22:45:31 +08:00
|
|
|
#include "hashmap.h"
|
2017-11-17 19:34:48 +08:00
|
|
|
#include "notes-utils.h"
|
|
|
|
|
#include "sigchain.h"
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
#include "unpack-trees.h"
|
|
|
|
|
#include "worktree.h"
|
2018-04-25 20:29:03 +08:00
|
|
|
#include "oidmap.h"
|
|
|
|
|
#include "oidset.h"
|
2018-05-19 13:28:22 +08:00
|
|
|
#include "commit-slab.h"
|
2018-05-21 02:40:06 +08:00
|
|
|
#include "alias.h"
|
2018-07-21 00:33:04 +08:00
|
|
|
#include "commit-reach.h"
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
#include "rebase-interactive.h"
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
#define GIT_REFLOG_ACTION "GIT_REFLOG_ACTION"
|
2011-08-04 18:39:11 +08:00
|
|
|
|
2019-02-12 01:16:58 +08:00
|
|
|
static const char sign_off_header[] = "Signed-off-by: ";
|
2013-02-12 18:17:32 +08:00
|
|
|
static const char cherry_picked_prefix[] = "(cherry picked from commit ";
|
2012-09-14 14:52:03 +08:00
|
|
|
|
2018-01-24 20:34:22 +08:00
|
|
|
GIT_PATH_FUNC(git_path_commit_editmsg, "COMMIT_EDITMSG")
|
|
|
|
|
|
2016-10-14 21:17:12 +08:00
|
|
|
GIT_PATH_FUNC(git_path_seq_dir, "sequencer")
|
|
|
|
|
|
|
|
|
|
static GIT_PATH_FUNC(git_path_todo_file, "sequencer/todo")
|
|
|
|
|
static GIT_PATH_FUNC(git_path_opts_file, "sequencer/opts")
|
|
|
|
|
static GIT_PATH_FUNC(git_path_head_file, "sequencer/head")
|
2016-12-08 05:51:32 +08:00
|
|
|
static GIT_PATH_FUNC(git_path_abort_safety_file, "sequencer/abort-safety")
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 17:38:57 +08:00
|
|
|
|
2017-01-02 23:26:28 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path, "rebase-merge")
|
|
|
|
|
/*
|
|
|
|
|
* The file containing rebase commands, comments, and empty lines.
|
|
|
|
|
* This file is created by "git rebase -i" then edited by the user. As
|
|
|
|
|
* the lines are processed, they are removed from the front of this
|
|
|
|
|
* file and written to the tail of 'done'.
|
|
|
|
|
*/
|
2018-08-11 00:51:28 +08:00
|
|
|
GIT_PATH_FUNC(rebase_path_todo, "rebase-merge/git-rebase-todo")
|
2019-03-06 03:18:03 +08:00
|
|
|
GIT_PATH_FUNC(rebase_path_todo_backup, "rebase-merge/git-rebase-todo.backup")
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
|
2017-01-02 23:27:00 +08:00
|
|
|
/*
|
|
|
|
|
* The rebase command lines that have already been processed. A line
|
|
|
|
|
* is moved here when it is first handled, before any associated user
|
|
|
|
|
* actions.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_done, "rebase-merge/done")
|
2017-01-02 23:36:20 +08:00
|
|
|
/*
|
|
|
|
|
* The file to keep track of how many commands were already processed (e.g.
|
|
|
|
|
* for the prompt).
|
|
|
|
|
*/
|
2018-07-10 03:25:35 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_msgnum, "rebase-merge/msgnum")
|
2017-01-02 23:36:20 +08:00
|
|
|
/*
|
|
|
|
|
* The file to keep track of how many commands are to be processed in total
|
|
|
|
|
* (e.g. for the prompt).
|
|
|
|
|
*/
|
2018-07-10 03:25:35 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_msgtotal, "rebase-merge/end")
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
/*
|
|
|
|
|
* The commit message that is planned to be used for any changes that
|
|
|
|
|
* need to be committed following a user interaction.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_message, "rebase-merge/message")
|
|
|
|
|
/*
|
|
|
|
|
* The file into which is accumulated the suggested commit message for
|
|
|
|
|
* squash/fixup commands. When the first of a series of squash/fixups
|
|
|
|
|
* is seen, the file is created and the commit message from the
|
|
|
|
|
* previous commit and from the first squash/fixup commit are written
|
|
|
|
|
* to it. The commit message for each subsequent squash/fixup commit
|
|
|
|
|
* is appended to the file as it is processed.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_squash_msg, "rebase-merge/message-squash")
|
|
|
|
|
/*
|
|
|
|
|
* If the current series of squash/fixups has not yet included a squash
|
|
|
|
|
* command, then this file exists and holds the commit message of the
|
|
|
|
|
* original "pick" commit. (If the series ends without a "squash"
|
|
|
|
|
* command, then this can be used as the commit message of the combined
|
|
|
|
|
* commit without opening the editor.)
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_fixup_msg, "rebase-merge/message-fixup")
|
2018-04-28 04:48:21 +08:00
|
|
|
/*
|
|
|
|
|
* This file contains the list fixup/squash commands that have been
|
|
|
|
|
* accumulated into message-fixup or message-squash so far.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_current_fixups, "rebase-merge/current-fixups")
|
2016-10-21 20:25:04 +08:00
|
|
|
/*
|
|
|
|
|
* A script to set the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, and
|
|
|
|
|
* GIT_AUTHOR_DATE that will be used for the commit that is currently
|
|
|
|
|
* being rebased.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_author_script, "rebase-merge/author-script")
|
2017-01-02 23:26:43 +08:00
|
|
|
/*
|
|
|
|
|
* When an "edit" rebase command is being processed, the SHA1 of the
|
|
|
|
|
* commit to be edited is recorded in this file. When "git rebase
|
|
|
|
|
* --continue" is executed, if there are any staged changes then they
|
|
|
|
|
* will be amended to the HEAD commit, but only provided the HEAD
|
|
|
|
|
* commit is still the commit to be edited. When any other rebase
|
|
|
|
|
* command is processed, this file is deleted.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_amend, "rebase-merge/amend")
|
|
|
|
|
/*
|
|
|
|
|
* When we stop at a given patch via the "edit" command, this file contains
|
|
|
|
|
* the abbreviated commit name of the corresponding patch.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_stopped_sha, "rebase-merge/stopped-sha")
|
2017-01-02 23:28:16 +08:00
|
|
|
/*
|
|
|
|
|
* For the post-rewrite hook, we make a list of rewritten commits and
|
|
|
|
|
* their new sha1s. The rewritten-pending list keeps the sha1s of
|
|
|
|
|
* commits that have been processed, but not committed yet,
|
|
|
|
|
* e.g. because they are waiting for a 'squash' command.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_rewritten_list, "rebase-merge/rewritten-list")
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_rewritten_pending,
|
|
|
|
|
"rebase-merge/rewritten-pending")
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
/*
|
|
|
|
|
* The path of the file containig the OID of the "squash onto" commit, i.e.
|
|
|
|
|
* the dummy commit used for `reset [new root]`.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_squash_onto, "rebase-merge/squash-onto")
|
|
|
|
|
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
/*
|
|
|
|
|
* The path of the file listing refs that need to be deleted after the rebase
|
|
|
|
|
* finishes. This is used by the `label` command to record the need for cleanup.
|
|
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_refs_to_delete, "rebase-merge/refs-to-delete")
|
|
|
|
|
|
2016-10-21 20:25:12 +08:00
|
|
|
/*
|
|
|
|
|
* The following files are written by git-rebase just after parsing the
|
2018-08-28 20:10:40 +08:00
|
|
|
* command-line.
|
2016-10-21 20:25:12 +08:00
|
|
|
*/
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_gpg_sign_opt, "rebase-merge/gpg_sign_opt")
|
2017-01-02 23:26:53 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_orig_head, "rebase-merge/orig-head")
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_verbose, "rebase-merge/verbose")
|
git-rebase, sequencer: extend --quiet option for the interactive machinery
While 'quiet' and 'interactive' may sound like antonyms, the interactive
machinery actually has logic that implements several
interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
which won't pop up an editor. The rewrite of interactive rebase in C
added a quiet option, though it only turns stats off. Since we want to
make the interactive machinery also take over for git-rebase--merge, it
should fully implement the --quiet option.
git-rebase--interactive was already somewhat quieter than
git-rebase--merge and git-rebase--am, possibly because cherry-pick has
just traditionally been quieter. As such, we only drop a few
informational messages -- "Rebasing (n/m)" and "Successfully rebased..."
Also, for simplicity, remove the differences in how quiet and verbose
options were recorded. Having one be signalled by the presence of a
"verbose" file in the state_dir, while the other was signalled by the
contents of a "quiet" file was just weirdly inconsistent. (This
inconsistency pre-dated the rewrite into C.) Make them consistent by
having them both key off the presence of the file.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:36 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_quiet, "rebase-merge/quiet")
|
2018-03-20 19:10:55 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_signoff, "rebase-merge/signoff")
|
2017-01-02 23:27:53 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_head_name, "rebase-merge/head-name")
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_onto, "rebase-merge/onto")
|
2017-01-02 23:28:27 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_autostash, "rebase-merge/autostash")
|
2017-01-02 23:28:30 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_strategy, "rebase-merge/strategy")
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_strategy_opts, "rebase-merge/strategy_opts")
|
2017-08-02 18:44:17 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_allow_rerere_autoupdate, "rebase-merge/allow_rerere_autoupdate")
|
2018-12-11 03:04:58 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_reschedule_failed_exec, "rebase-merge/reschedule-failed-exec")
|
2016-10-21 20:25:04 +08:00
|
|
|
|
2017-12-13 19:46:21 +08:00
|
|
|
static int git_sequencer_config(const char *k, const char *v, void *cb)
|
|
|
|
|
{
|
|
|
|
|
struct replay_opts *opts = cb;
|
|
|
|
|
int status;
|
|
|
|
|
|
|
|
|
|
if (!strcmp(k, "commit.cleanup")) {
|
|
|
|
|
const char *s;
|
|
|
|
|
|
|
|
|
|
status = git_config_string(&s, k, v);
|
|
|
|
|
if (status)
|
|
|
|
|
return status;
|
|
|
|
|
|
2019-03-29 19:08:42 +08:00
|
|
|
if (!strcmp(s, "verbatim")) {
|
2017-12-13 19:46:21 +08:00
|
|
|
opts->default_msg_cleanup = COMMIT_MSG_CLEANUP_NONE;
|
2019-03-29 19:08:42 +08:00
|
|
|
opts->explicit_cleanup = 1;
|
|
|
|
|
} else if (!strcmp(s, "whitespace")) {
|
2017-12-13 19:46:21 +08:00
|
|
|
opts->default_msg_cleanup = COMMIT_MSG_CLEANUP_SPACE;
|
2019-03-29 19:08:42 +08:00
|
|
|
opts->explicit_cleanup = 1;
|
|
|
|
|
} else if (!strcmp(s, "strip")) {
|
2017-12-13 19:46:21 +08:00
|
|
|
opts->default_msg_cleanup = COMMIT_MSG_CLEANUP_ALL;
|
2019-03-29 19:08:42 +08:00
|
|
|
opts->explicit_cleanup = 1;
|
|
|
|
|
} else if (!strcmp(s, "scissors")) {
|
2019-04-17 18:23:30 +08:00
|
|
|
opts->default_msg_cleanup = COMMIT_MSG_CLEANUP_SCISSORS;
|
2019-03-29 19:08:42 +08:00
|
|
|
opts->explicit_cleanup = 1;
|
|
|
|
|
} else {
|
2017-12-13 19:46:21 +08:00
|
|
|
warning(_("invalid commit message cleanup mode '%s'"),
|
|
|
|
|
s);
|
2019-03-29 19:08:42 +08:00
|
|
|
}
|
2017-12-13 19:46:21 +08:00
|
|
|
|
2018-06-02 04:01:46 +08:00
|
|
|
free((char *)s);
|
2017-12-13 19:46:21 +08:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!strcmp(k, "commit.gpgsign")) {
|
2017-12-22 19:50:50 +08:00
|
|
|
opts->gpg_sign = git_config_bool(k, v) ? xstrdup("") : NULL;
|
2017-12-13 19:46:21 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
status = git_gpg_config(k, v, NULL);
|
|
|
|
|
if (status)
|
|
|
|
|
return status;
|
|
|
|
|
|
|
|
|
|
return git_diff_basic_config(k, v, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void sequencer_init_config(struct replay_opts *opts)
|
|
|
|
|
{
|
|
|
|
|
opts->default_msg_cleanup = COMMIT_MSG_CLEANUP_NONE;
|
|
|
|
|
git_config(git_sequencer_config, opts);
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:25:04 +08:00
|
|
|
static inline int is_rebase_i(const struct replay_opts *opts)
|
|
|
|
|
{
|
2017-01-02 23:26:28 +08:00
|
|
|
return opts->action == REPLAY_INTERACTIVE_REBASE;
|
2016-10-21 20:25:04 +08:00
|
|
|
}
|
|
|
|
|
|
2016-10-14 21:17:20 +08:00
|
|
|
static const char *get_dir(const struct replay_opts *opts)
|
|
|
|
|
{
|
2017-01-02 23:26:28 +08:00
|
|
|
if (is_rebase_i(opts))
|
|
|
|
|
return rebase_path();
|
2016-10-14 21:17:20 +08:00
|
|
|
return git_path_seq_dir();
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:24:32 +08:00
|
|
|
static const char *get_todo_path(const struct replay_opts *opts)
|
|
|
|
|
{
|
2017-01-02 23:26:28 +08:00
|
|
|
if (is_rebase_i(opts))
|
|
|
|
|
return rebase_path_todo();
|
2016-10-21 20:24:32 +08:00
|
|
|
return git_path_todo_file();
|
|
|
|
|
}
|
|
|
|
|
|
2013-02-12 18:17:35 +08:00
|
|
|
/*
|
|
|
|
|
* Returns 0 for non-conforming footer
|
|
|
|
|
* Returns 1 for conforming footer
|
|
|
|
|
* Returns 2 when sob exists within conforming footer
|
|
|
|
|
* Returns 3 when sob exists within conforming footer as last entry
|
|
|
|
|
*/
|
|
|
|
|
static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
|
2018-08-23 08:50:51 +08:00
|
|
|
size_t ignore_footer)
|
2013-02-12 18:17:34 +08:00
|
|
|
{
|
2018-08-23 08:46:23 +08:00
|
|
|
struct process_trailer_options opts = PROCESS_TRAILER_OPTIONS_INIT;
|
2016-11-03 01:29:20 +08:00
|
|
|
struct trailer_info info;
|
2018-08-23 08:45:44 +08:00
|
|
|
size_t i;
|
2016-11-03 01:29:20 +08:00
|
|
|
int found_sob = 0, found_sob_last = 0;
|
2013-02-12 18:17:34 +08:00
|
|
|
|
2018-08-23 08:50:37 +08:00
|
|
|
opts.no_divider = 1;
|
|
|
|
|
|
2018-08-23 08:46:23 +08:00
|
|
|
trailer_info_get(&info, sb->buf, &opts);
|
2013-02-12 18:17:34 +08:00
|
|
|
|
2016-11-03 01:29:20 +08:00
|
|
|
if (info.trailer_start == info.trailer_end)
|
2013-02-12 18:17:34 +08:00
|
|
|
return 0;
|
|
|
|
|
|
2016-11-03 01:29:20 +08:00
|
|
|
for (i = 0; i < info.trailer_nr; i++)
|
|
|
|
|
if (sob && !strncmp(info.trailers[i], sob->buf, sob->len)) {
|
|
|
|
|
found_sob = 1;
|
|
|
|
|
if (i == info.trailer_nr - 1)
|
|
|
|
|
found_sob_last = 1;
|
|
|
|
|
}
|
2013-02-12 18:17:34 +08:00
|
|
|
|
2016-11-03 01:29:20 +08:00
|
|
|
trailer_info_release(&info);
|
2013-02-12 18:17:35 +08:00
|
|
|
|
2016-11-03 01:29:20 +08:00
|
|
|
if (found_sob_last)
|
2013-02-12 18:17:35 +08:00
|
|
|
return 3;
|
|
|
|
|
if (found_sob)
|
|
|
|
|
return 2;
|
2013-02-12 18:17:34 +08:00
|
|
|
return 1;
|
|
|
|
|
}
|
2012-09-14 14:52:03 +08:00
|
|
|
|
2016-10-21 20:25:12 +08:00
|
|
|
static const char *gpg_sign_opt_quoted(struct replay_opts *opts)
|
|
|
|
|
{
|
|
|
|
|
static struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
if (opts->gpg_sign)
|
|
|
|
|
sq_quotef(&buf, "-S%s", opts->gpg_sign);
|
|
|
|
|
return buf.buf;
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:24:55 +08:00
|
|
|
int sequencer_remove_state(struct replay_opts *opts)
|
2011-08-04 18:39:11 +08:00
|
|
|
{
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2019-05-15 02:03:48 +08:00
|
|
|
int i, ret = 0;
|
2016-10-21 20:24:13 +08:00
|
|
|
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
if (is_rebase_i(opts) &&
|
|
|
|
|
strbuf_read_file(&buf, rebase_path_refs_to_delete(), 0) > 0) {
|
|
|
|
|
char *p = buf.buf;
|
|
|
|
|
while (*p) {
|
|
|
|
|
char *eol = strchr(p, '\n');
|
|
|
|
|
if (eol)
|
|
|
|
|
*eol = '\0';
|
2019-05-15 02:03:48 +08:00
|
|
|
if (delete_ref("(rebase -i) cleanup", p, NULL, 0) < 0) {
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
warning(_("could not delete '%s'"), p);
|
2019-05-15 02:03:48 +08:00
|
|
|
ret = -1;
|
|
|
|
|
}
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
if (!eol)
|
|
|
|
|
break;
|
|
|
|
|
p = eol + 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:24:13 +08:00
|
|
|
free(opts->gpg_sign);
|
|
|
|
|
free(opts->strategy);
|
|
|
|
|
for (i = 0; i < opts->xopts_nr; i++)
|
|
|
|
|
free(opts->xopts[i]);
|
|
|
|
|
free(opts->xopts);
|
2018-04-28 04:48:21 +08:00
|
|
|
strbuf_release(&opts->current_fixups);
|
2011-08-04 18:39:11 +08:00
|
|
|
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
strbuf_addstr(&buf, get_dir(opts));
|
2019-05-15 02:03:48 +08:00
|
|
|
if (remove_dir_recursively(&buf, 0))
|
|
|
|
|
ret = error(_("could not remove '%s'"), buf.buf);
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
strbuf_release(&buf);
|
2016-10-21 20:24:55 +08:00
|
|
|
|
2019-05-15 02:03:48 +08:00
|
|
|
return ret;
|
2011-08-04 18:39:11 +08:00
|
|
|
}
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
static const char *action_name(const struct replay_opts *opts)
|
|
|
|
|
{
|
2017-01-02 23:26:28 +08:00
|
|
|
switch (opts->action) {
|
|
|
|
|
case REPLAY_REVERT:
|
|
|
|
|
return N_("revert");
|
|
|
|
|
case REPLAY_PICK:
|
|
|
|
|
return N_("cherry-pick");
|
|
|
|
|
case REPLAY_INTERACTIVE_REBASE:
|
|
|
|
|
return N_("rebase -i");
|
|
|
|
|
}
|
2018-07-21 15:49:19 +08:00
|
|
|
die(_("unknown action: %d"), opts->action);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct commit_message {
|
|
|
|
|
char *parent_label;
|
2016-02-23 06:44:57 +08:00
|
|
|
char *label;
|
|
|
|
|
char *subject;
|
2012-01-12 02:15:57 +08:00
|
|
|
const char *message;
|
|
|
|
|
};
|
|
|
|
|
|
2016-10-21 20:24:37 +08:00
|
|
|
static const char *short_commit_name(struct commit *commit)
|
|
|
|
|
{
|
2018-03-12 10:27:30 +08:00
|
|
|
return find_unique_abbrev(&commit->object.oid, DEFAULT_ABBREV);
|
2016-10-21 20:24:37 +08:00
|
|
|
}
|
|
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
static int get_message(struct commit *commit, struct commit_message *out)
|
|
|
|
|
{
|
|
|
|
|
const char *abbrev, *subject;
|
2016-02-23 06:44:57 +08:00
|
|
|
int subject_len;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2016-02-23 06:44:57 +08:00
|
|
|
out->message = logmsg_reencode(commit, NULL, get_commit_output_encoding());
|
2016-10-21 20:24:37 +08:00
|
|
|
abbrev = short_commit_name(commit);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
subject_len = find_commit_subject(out->message, &subject);
|
|
|
|
|
|
2016-02-23 06:44:57 +08:00
|
|
|
out->subject = xmemdupz(subject, subject_len);
|
|
|
|
|
out->label = xstrfmt("%s... %s", abbrev, out->subject);
|
|
|
|
|
out->parent_label = xstrfmt("parent of %s", out->label);
|
|
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-11 05:39:35 +08:00
|
|
|
static void free_message(struct commit *commit, struct commit_message *msg)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
|
|
|
|
free(msg->parent_label);
|
2016-02-23 06:44:57 +08:00
|
|
|
free(msg->label);
|
|
|
|
|
free(msg->subject);
|
2014-06-11 05:41:39 +08:00
|
|
|
unuse_commit_buffer(commit, msg->message);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static void print_advice(struct repository *r, int show_hint,
|
|
|
|
|
struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
|
|
|
|
char *msg = getenv("GIT_CHERRY_PICK_HELP");
|
|
|
|
|
|
|
|
|
|
if (msg) {
|
|
|
|
|
fprintf(stderr, "%s\n", msg);
|
|
|
|
|
/*
|
2013-04-12 06:36:10 +08:00
|
|
|
* A conflict has occurred but the porcelain
|
2012-01-12 02:15:57 +08:00
|
|
|
* (typically rebase --interactive) wants to take care
|
|
|
|
|
* of the commit itself so remove CHERRY_PICK_HEAD
|
|
|
|
|
*/
|
2018-11-10 13:48:57 +08:00
|
|
|
unlink(git_path_cherry_pick_head(r));
|
2012-01-12 02:15:57 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-22 08:44:17 +08:00
|
|
|
if (show_hint) {
|
|
|
|
|
if (opts->no_commit)
|
|
|
|
|
advise(_("after resolving the conflicts, mark the corrected paths\n"
|
|
|
|
|
"with 'git add <paths>' or 'git rm <paths>'"));
|
|
|
|
|
else
|
|
|
|
|
advise(_("after resolving the conflicts, mark the corrected paths\n"
|
|
|
|
|
"with 'git add <paths>' or 'git rm <paths>'\n"
|
|
|
|
|
"and commit the result with 'git commit'"));
|
|
|
|
|
}
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2019-03-06 03:18:01 +08:00
|
|
|
static int write_message(const void *buf, size_t len, const char *filename,
|
|
|
|
|
int append_eol)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2018-02-28 05:30:09 +08:00
|
|
|
struct lock_file msg_file = LOCK_INIT;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2016-09-09 22:37:05 +08:00
|
|
|
int msg_fd = hold_lock_file_for_update(&msg_file, filename, 0);
|
|
|
|
|
if (msg_fd < 0)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error_errno(_("could not lock '%s'"), filename);
|
2016-10-21 20:26:05 +08:00
|
|
|
if (write_in_full(msg_fd, buf, len) < 0) {
|
2018-04-25 20:28:17 +08:00
|
|
|
error_errno(_("could not write to '%s'"), filename);
|
2016-10-21 20:26:00 +08:00
|
|
|
rollback_lock_file(&msg_file);
|
2018-04-25 20:28:17 +08:00
|
|
|
return -1;
|
2016-10-21 20:26:00 +08:00
|
|
|
}
|
2016-10-21 20:26:09 +08:00
|
|
|
if (append_eol && write(msg_fd, "\n", 1) < 0) {
|
2018-04-25 20:28:17 +08:00
|
|
|
error_errno(_("could not write eol to '%s'"), filename);
|
2016-10-21 20:26:09 +08:00
|
|
|
rollback_lock_file(&msg_file);
|
2018-04-25 20:28:17 +08:00
|
|
|
return -1;
|
2016-10-21 20:26:09 +08:00
|
|
|
}
|
2018-03-01 03:07:58 +08:00
|
|
|
if (commit_lock_file(&msg_file) < 0)
|
|
|
|
|
return error(_("failed to finalize '%s'"), filename);
|
2016-09-09 22:37:05 +08:00
|
|
|
|
|
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:25:08 +08:00
|
|
|
/*
|
|
|
|
|
* Reads a file that was presumably written by a shell script, i.e. with an
|
|
|
|
|
* end-of-line marker that needs to be stripped.
|
|
|
|
|
*
|
|
|
|
|
* Note that only the last end-of-line marker is stripped, consistent with the
|
|
|
|
|
* behavior of "$(cat path)" in a shell script.
|
|
|
|
|
*
|
|
|
|
|
* Returns 1 if the file was read, 0 if it could not be read or does not exist.
|
|
|
|
|
*/
|
|
|
|
|
static int read_oneliner(struct strbuf *buf,
|
|
|
|
|
const char *path, int skip_if_empty)
|
|
|
|
|
{
|
|
|
|
|
int orig_len = buf->len;
|
|
|
|
|
|
|
|
|
|
if (!file_exists(path))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
if (strbuf_read_file(buf, path, 0) < 0) {
|
|
|
|
|
warning_errno(_("could not read '%s'"), path);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (buf->len > orig_len && buf->buf[buf->len - 1] == '\n') {
|
|
|
|
|
if (--buf->len > orig_len && buf->buf[buf->len - 1] == '\r')
|
|
|
|
|
--buf->len;
|
|
|
|
|
buf->buf[buf->len] = '\0';
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (skip_if_empty && buf->len == orig_len)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static struct tree *empty_tree(struct repository *r)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2018-11-10 13:48:57 +08:00
|
|
|
return lookup_tree(r, the_hash_algo->empty_tree);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2019-01-12 10:13:26 +08:00
|
|
|
static int error_dirty_index(struct repository *repo, struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2019-01-12 10:13:26 +08:00
|
|
|
if (repo_read_index_unmerged(repo))
|
2016-10-21 20:26:17 +08:00
|
|
|
return error_resolve_conflict(_(action_name(opts)));
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2016-10-21 20:26:25 +08:00
|
|
|
error(_("your local changes would be overwritten by %s."),
|
2016-10-21 20:26:17 +08:00
|
|
|
_(action_name(opts)));
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
if (advice_commit_before_merge)
|
2016-10-21 20:26:25 +08:00
|
|
|
advise(_("commit your changes or stash them to proceed."));
|
2012-01-12 02:15:57 +08:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-08 05:51:32 +08:00
|
|
|
static void update_abort_safety_file(void)
|
|
|
|
|
{
|
|
|
|
|
struct object_id head;
|
|
|
|
|
|
|
|
|
|
/* Do nothing on a single-pick */
|
|
|
|
|
if (!file_exists(git_path_seq_dir()))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (!get_oid("HEAD", &head))
|
|
|
|
|
write_file(git_path_abort_safety_file(), "%s", oid_to_hex(&head));
|
|
|
|
|
else
|
|
|
|
|
write_file(git_path_abort_safety_file(), "%s", "");
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int fast_forward_to(struct repository *r,
|
|
|
|
|
const struct object_id *to,
|
|
|
|
|
const struct object_id *from,
|
|
|
|
|
int unborn,
|
|
|
|
|
struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2014-04-17 06:37:45 +08:00
|
|
|
struct ref_transaction *transaction;
|
2013-06-19 15:37:09 +08:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2014-04-17 06:37:45 +08:00
|
|
|
struct strbuf err = STRBUF_INIT;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2019-01-12 10:13:26 +08:00
|
|
|
repo_read_index(r);
|
2018-11-10 13:48:56 +08:00
|
|
|
if (checkout_fast_forward(r, from, to, 1))
|
2016-09-09 22:37:55 +08:00
|
|
|
return -1; /* the callee should have complained already */
|
2014-04-17 02:56:52 +08:00
|
|
|
|
2016-10-21 20:26:17 +08:00
|
|
|
strbuf_addf(&sb, _("%s: fast-forward"), _(action_name(opts)));
|
2014-04-17 06:37:45 +08:00
|
|
|
|
|
|
|
|
transaction = ref_transaction_begin(&err);
|
|
|
|
|
if (!transaction ||
|
|
|
|
|
ref_transaction_update(transaction, "HEAD",
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
to, unborn && !is_rebase_i(opts) ?
|
|
|
|
|
&null_oid : from,
|
2015-02-18 01:00:15 +08:00
|
|
|
0, sb.buf, &err) ||
|
2014-05-01 03:22:42 +08:00
|
|
|
ref_transaction_commit(transaction, &err)) {
|
2014-04-17 06:37:45 +08:00
|
|
|
ref_transaction_free(transaction);
|
|
|
|
|
error("%s", err.buf);
|
|
|
|
|
strbuf_release(&sb);
|
|
|
|
|
strbuf_release(&err);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
2014-04-17 02:56:52 +08:00
|
|
|
|
2013-06-19 15:37:09 +08:00
|
|
|
strbuf_release(&sb);
|
2014-04-17 06:37:45 +08:00
|
|
|
strbuf_release(&err);
|
|
|
|
|
ref_transaction_free(transaction);
|
2016-12-08 05:51:32 +08:00
|
|
|
update_abort_safety_file();
|
2014-04-17 06:37:45 +08:00
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2019-04-17 18:23:25 +08:00
|
|
|
enum commit_msg_cleanup_mode get_cleanup_mode(const char *cleanup_arg,
|
|
|
|
|
int use_editor)
|
|
|
|
|
{
|
|
|
|
|
if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
|
|
|
|
|
return use_editor ? COMMIT_MSG_CLEANUP_ALL :
|
|
|
|
|
COMMIT_MSG_CLEANUP_SPACE;
|
|
|
|
|
else if (!strcmp(cleanup_arg, "verbatim"))
|
|
|
|
|
return COMMIT_MSG_CLEANUP_NONE;
|
|
|
|
|
else if (!strcmp(cleanup_arg, "whitespace"))
|
|
|
|
|
return COMMIT_MSG_CLEANUP_SPACE;
|
|
|
|
|
else if (!strcmp(cleanup_arg, "strip"))
|
|
|
|
|
return COMMIT_MSG_CLEANUP_ALL;
|
|
|
|
|
else if (!strcmp(cleanup_arg, "scissors"))
|
|
|
|
|
return use_editor ? COMMIT_MSG_CLEANUP_SCISSORS :
|
|
|
|
|
COMMIT_MSG_CLEANUP_SPACE;
|
|
|
|
|
else
|
|
|
|
|
die(_("Invalid cleanup mode %s"), cleanup_arg);
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-17 18:23:29 +08:00
|
|
|
/*
|
|
|
|
|
* NB using int rather than enum cleanup_mode to stop clang's
|
|
|
|
|
* -Wtautological-constant-out-of-range-compare complaining that the comparison
|
|
|
|
|
* is always true.
|
|
|
|
|
*/
|
|
|
|
|
static const char *describe_cleanup_mode(int cleanup_mode)
|
|
|
|
|
{
|
|
|
|
|
static const char *modes[] = { "whitespace",
|
|
|
|
|
"verbatim",
|
|
|
|
|
"scissors",
|
|
|
|
|
"strip" };
|
|
|
|
|
|
|
|
|
|
if (cleanup_mode < ARRAY_SIZE(modes))
|
|
|
|
|
return modes[cleanup_mode];
|
|
|
|
|
|
|
|
|
|
BUG("invalid cleanup_mode provided (%d)", cleanup_mode);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
void append_conflicts_hint(struct index_state *istate,
|
2019-04-17 18:23:30 +08:00
|
|
|
struct strbuf *msgbuf, enum commit_msg_cleanup_mode cleanup_mode)
|
2014-10-25 02:34:59 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
2019-04-17 18:23:30 +08:00
|
|
|
if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS) {
|
|
|
|
|
strbuf_addch(msgbuf, '\n');
|
|
|
|
|
wt_status_append_cut_line(msgbuf);
|
|
|
|
|
strbuf_addch(msgbuf, comment_line_char);
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-29 04:04:38 +08:00
|
|
|
strbuf_addch(msgbuf, '\n');
|
|
|
|
|
strbuf_commented_addf(msgbuf, "Conflicts:\n");
|
2018-11-10 13:48:56 +08:00
|
|
|
for (i = 0; i < istate->cache_nr;) {
|
|
|
|
|
const struct cache_entry *ce = istate->cache[i++];
|
2014-10-25 02:34:59 +08:00
|
|
|
if (ce_stage(ce)) {
|
2014-10-29 04:04:38 +08:00
|
|
|
strbuf_commented_addf(msgbuf, "\t%s\n", ce->name);
|
2018-11-10 13:48:56 +08:00
|
|
|
while (i < istate->cache_nr &&
|
|
|
|
|
!strcmp(ce->name, istate->cache[i]->name))
|
2014-10-25 02:34:59 +08:00
|
|
|
i++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_recursive_merge(struct repository *r,
|
|
|
|
|
struct commit *base, struct commit *next,
|
2012-01-12 02:15:57 +08:00
|
|
|
const char *base_label, const char *next_label,
|
2017-05-07 06:10:36 +08:00
|
|
|
struct object_id *head, struct strbuf *msgbuf,
|
2012-01-12 02:15:57 +08:00
|
|
|
struct replay_opts *opts)
|
|
|
|
|
{
|
|
|
|
|
struct merge_options o;
|
|
|
|
|
struct tree *result, *next_tree, *base_tree, *head_tree;
|
2014-06-13 20:19:23 +08:00
|
|
|
int clean;
|
2016-10-21 20:24:13 +08:00
|
|
|
char **xopt;
|
2018-02-28 05:30:09 +08:00
|
|
|
struct lock_file index_lock = LOCK_INIT;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2019-01-12 10:13:24 +08:00
|
|
|
if (repo_hold_locked_index(r, &index_lock, LOCK_REPORT_ON_ERROR) < 0)
|
2017-11-15 18:41:25 +08:00
|
|
|
return -1;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2019-01-12 10:13:26 +08:00
|
|
|
repo_read_index(r);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2019-01-12 10:13:29 +08:00
|
|
|
init_merge_options(&o, r);
|
2012-01-12 02:15:57 +08:00
|
|
|
o.ancestor = base ? base_label : "(empty tree)";
|
|
|
|
|
o.branch1 = "HEAD";
|
|
|
|
|
o.branch2 = next ? next_label : "(empty tree)";
|
2017-01-02 23:35:39 +08:00
|
|
|
if (is_rebase_i(opts))
|
|
|
|
|
o.buffer_output = 2;
|
2017-11-14 04:16:00 +08:00
|
|
|
o.show_rename_progress = 1;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
head_tree = parse_tree_indirect(head);
|
2018-11-10 13:48:57 +08:00
|
|
|
next_tree = next ? get_commit_tree(next) : empty_tree(r);
|
|
|
|
|
base_tree = base ? get_commit_tree(base) : empty_tree(r);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
for (xopt = opts->xopts; xopt != opts->xopts + opts->xopts_nr; xopt++)
|
|
|
|
|
parse_merge_opt(&o, *xopt);
|
|
|
|
|
|
|
|
|
|
clean = merge_trees(&o,
|
|
|
|
|
head_tree,
|
|
|
|
|
next_tree, base_tree, &result);
|
2017-01-02 23:35:39 +08:00
|
|
|
if (is_rebase_i(opts) && clean <= 0)
|
|
|
|
|
fputs(o.obuf.buf, stdout);
|
2016-08-01 19:44:53 +08:00
|
|
|
strbuf_release(&o.obuf);
|
2017-11-14 04:15:57 +08:00
|
|
|
diff_warn_rename_limit("merge.renamelimit", o.needed_rename_limit, 0);
|
2018-02-28 05:30:10 +08:00
|
|
|
if (clean < 0) {
|
|
|
|
|
rollback_lock_file(&index_lock);
|
prepare the builtins for a libified merge_recursive()
Previously, callers of merge_trees() or merge_recursive() expected that
code to die() with an error message. This used to be okay because we
called those commands from scripts, and had a chance to print out a
message in case the command failed fatally (read: with exit code 128).
As scripting incurs its own set of problems (portability, speed,
idiosyncrasies of different shells, limited data structures leading to
inefficient code), we are converting more and more of these scripts into
builtins, using library functions directly.
We already tried to use merge_recursive() directly in the builtin
git-am, for example. Unfortunately, we had to roll it back temporarily
because some of the code in merge-recursive.c still deemed it okay to
call die(), when the builtin am code really wanted to print out a useful
advice after the merge failed fatally. In the next commits, we want to
fix that.
The code touched by this commit expected merge_trees() to die() with
some useful message when there is an error condition, but merge_trees()
is going to be improved by converting all die() calls to return error()
instead (i.e. return value -1 after printing out the message as before),
so that the caller can react more flexibly.
This is a step to prepare for the version of merge_trees() that no
longer dies, even if we just imitate the previous behavior by calling
exit(128): this is what callers of e.g. `git merge` have come to expect.
Note that the callers of the sequencer (revert and cherry-pick) already
fail fast even for the return value -1; The only difference is that they
now get a chance to say "<command> failed".
A caller of merge_trees() might want handle error messages themselves
(or even suppress them). As this patch is already complex enough, we
leave that change for a later patch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27 00:06:02 +08:00
|
|
|
return clean;
|
2018-02-28 05:30:10 +08:00
|
|
|
}
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (write_locked_index(r->index, &index_lock,
|
2018-03-02 04:40:20 +08:00
|
|
|
COMMIT_LOCK | SKIP_IF_UNCHANGED))
|
C style: use standard style for "TRANSLATORS" comments
Change all the "TRANSLATORS: [...]" comments in the C code to use the
regular Git coding style, and amend the style guide so that the
example there uses that style.
This custom style was necessary back in 2010 when the gettext support
was initially added, and was subsequently documented in commit
cbcfd4e3ea ("i18n: mention "TRANSLATORS:" marker in
Documentation/CodingGuidelines", 2014-04-18).
GNU xgettext hasn't had the parsing limitation that necessitated this
exception for almost 3 years. Since its 0.19 release on 2014-06-02
it's been able to recognize TRANSLATOR comments in the standard Git
comment syntax[1].
Usually we'd like to keep compatibility with software that's that
young, but in this case literally the only person who needs to be
using a gettext newer than 3 years old is Jiang Xin (the only person
who runs & commits "make pot" results), so I think in this case we can
make an exception.
This xgettext parsing feature was added after a thread on the Git
mailing list[2] which continued on the bug-gettext[3] list, but we
never subsequently changed our style & styleguide, do so.
There are already longstanding changes in git that use the standard
comment style & have their TRANSLATORS comments extracted properly
without getting the literal "*"'s mixed up in the text, as would
happen before xgettext 0.19.
Commit 7ff2683253 ("builtin-am: implement -i/--interactive",
2015-08-04) added one such comment, which in commit df0617bfa7 ("l10n:
git.pot: v2.6.0 round 1 (123 new, 41 removed)", 2015-09-05) got picked
up in the po/git.pot file with the right format, showing that Jiang
already runs a modern xgettext.
The xgettext parser does not handle the sort of non-standard comment
style that I'm amending here in sequencer.c, but that isn't standard
Git comment syntax anyway. With this change to sequencer.c & "make
pot" the comment in the pot file is now correct:
#. TRANSLATORS: %s will be "revert", "cherry-pick" or
-#. * "rebase -i".
+#. "rebase -i".
1. http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=10af7fe6bd
2. <2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com>
(https://public-inbox.org/git/2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com/)
3. https://lists.gnu.org/archive/html/bug-gettext/2014-04/msg00016.html
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-12 05:20:12 +08:00
|
|
|
/*
|
|
|
|
|
* TRANSLATORS: %s will be "revert", "cherry-pick" or
|
2017-01-02 23:26:28 +08:00
|
|
|
* "rebase -i".
|
|
|
|
|
*/
|
2016-09-09 22:37:10 +08:00
|
|
|
return error(_("%s: Unable to write new index file"),
|
2016-10-21 20:26:17 +08:00
|
|
|
_(action_name(opts)));
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2014-10-25 02:34:59 +08:00
|
|
|
if (!clean)
|
2019-04-17 18:23:30 +08:00
|
|
|
append_conflicts_hint(r->index, msgbuf,
|
|
|
|
|
opts->default_msg_cleanup);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
return !clean;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static struct object_id *get_cache_tree_oid(struct index_state *istate)
|
2018-05-04 07:01:15 +08:00
|
|
|
{
|
2018-11-10 13:48:56 +08:00
|
|
|
if (!istate->cache_tree)
|
|
|
|
|
istate->cache_tree = cache_tree();
|
2018-05-04 07:01:15 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (!cache_tree_fully_valid(istate->cache_tree))
|
|
|
|
|
if (cache_tree_update(istate, 0)) {
|
2018-05-04 07:01:15 +08:00
|
|
|
error(_("unable to update cache tree"));
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
return &istate->cache_tree->oid;
|
2018-05-04 07:01:15 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int is_index_unchanged(struct repository *r)
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
{
|
2018-05-04 07:01:15 +08:00
|
|
|
struct object_id head_oid, *cache_tree_oid;
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
struct commit *head_commit;
|
2018-11-10 13:48:57 +08:00
|
|
|
struct index_state *istate = r->index;
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
|
refs: convert resolve_ref_unsafe to struct object_id
Convert resolve_ref_unsafe to take a pointer to struct object_id by
converting one remaining caller to use struct object_id, removing the
temporary NULL pointer check in expand_ref, converting the declaration
and definition, and applying the following semantic patch:
@@
expression E1, E2, E3, E4;
@@
- resolve_ref_unsafe(E1, E2, E3.hash, E4)
+ resolve_ref_unsafe(E1, E2, &E3, E4)
@@
expression E1, E2, E3, E4;
@@
- resolve_ref_unsafe(E1, E2, E3->hash, E4)
+ resolve_ref_unsafe(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-16 06:07:09 +08:00
|
|
|
if (!resolve_ref_unsafe("HEAD", RESOLVE_REF_READING, &head_oid, NULL))
|
2017-12-23 07:55:43 +08:00
|
|
|
return error(_("could not resolve HEAD commit"));
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
head_commit = lookup_commit(r, &head_oid);
|
2012-05-03 20:10:22 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If head_commit is NULL, check_commit, called from
|
|
|
|
|
* lookup_commit, would have indicated that head_commit is not
|
|
|
|
|
* a commit object already. parse_commit() will return failure
|
|
|
|
|
* without further complaints in such a case. Otherwise, if
|
|
|
|
|
* the commit is invalid, parse_commit() will complain. So
|
|
|
|
|
* there is nothing for us to say here. Just return failure.
|
|
|
|
|
*/
|
|
|
|
|
if (parse_commit(head_commit))
|
|
|
|
|
return -1;
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (!(cache_tree_oid = get_cache_tree_oid(istate)))
|
2018-05-04 07:01:15 +08:00
|
|
|
return -1;
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
return oideq(cache_tree_oid, get_commit_tree_oid(head_commit));
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:27:18 +08:00
|
|
|
static int write_author_script(const char *message)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
const char *eol;
|
|
|
|
|
int res;
|
|
|
|
|
|
|
|
|
|
for (;;)
|
|
|
|
|
if (!*message || starts_with(message, "\n")) {
|
|
|
|
|
missing_author:
|
|
|
|
|
/* Missing 'author' line? */
|
|
|
|
|
unlink(rebase_path_author_script());
|
|
|
|
|
return 0;
|
|
|
|
|
} else if (skip_prefix(message, "author ", &message))
|
|
|
|
|
break;
|
|
|
|
|
else if ((eol = strchr(message, '\n')))
|
|
|
|
|
message = eol + 1;
|
|
|
|
|
else
|
|
|
|
|
goto missing_author;
|
|
|
|
|
|
|
|
|
|
strbuf_addstr(&buf, "GIT_AUTHOR_NAME='");
|
|
|
|
|
while (*message && *message != '\n' && *message != '\r')
|
|
|
|
|
if (skip_prefix(message, " <", &message))
|
|
|
|
|
break;
|
|
|
|
|
else if (*message != '\'')
|
|
|
|
|
strbuf_addch(&buf, *(message++));
|
|
|
|
|
else
|
2018-08-07 17:34:52 +08:00
|
|
|
strbuf_addf(&buf, "'\\%c'", *(message++));
|
2017-01-02 23:27:18 +08:00
|
|
|
strbuf_addstr(&buf, "'\nGIT_AUTHOR_EMAIL='");
|
|
|
|
|
while (*message && *message != '\n' && *message != '\r')
|
|
|
|
|
if (skip_prefix(message, "> ", &message))
|
|
|
|
|
break;
|
|
|
|
|
else if (*message != '\'')
|
|
|
|
|
strbuf_addch(&buf, *(message++));
|
|
|
|
|
else
|
2018-08-07 17:34:52 +08:00
|
|
|
strbuf_addf(&buf, "'\\%c'", *(message++));
|
2017-01-02 23:27:18 +08:00
|
|
|
strbuf_addstr(&buf, "'\nGIT_AUTHOR_DATE='@");
|
|
|
|
|
while (*message && *message != '\n' && *message != '\r')
|
|
|
|
|
if (*message != '\'')
|
|
|
|
|
strbuf_addch(&buf, *(message++));
|
|
|
|
|
else
|
2018-08-07 17:34:52 +08:00
|
|
|
strbuf_addf(&buf, "'\\%c'", *(message++));
|
2018-07-31 15:33:29 +08:00
|
|
|
strbuf_addch(&buf, '\'');
|
2017-01-02 23:27:18 +08:00
|
|
|
res = write_message(buf.buf, buf.len, rebase_path_author_script(), 1);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-31 18:15:55 +08:00
|
|
|
/**
|
|
|
|
|
* Take a series of KEY='VALUE' lines where VALUE part is
|
|
|
|
|
* sq-quoted, and append <KEY, VALUE> at the end of the string list
|
|
|
|
|
*/
|
|
|
|
|
static int parse_key_value_squoted(char *buf, struct string_list *list)
|
|
|
|
|
{
|
|
|
|
|
while (*buf) {
|
|
|
|
|
struct string_list_item *item;
|
|
|
|
|
char *np;
|
|
|
|
|
char *cp = strchr(buf, '=');
|
|
|
|
|
if (!cp) {
|
|
|
|
|
np = strchrnul(buf, '\n');
|
|
|
|
|
return error(_("no key present in '%.*s'"),
|
|
|
|
|
(int) (np - buf), buf);
|
|
|
|
|
}
|
|
|
|
|
np = strchrnul(cp, '\n');
|
|
|
|
|
*cp++ = '\0';
|
|
|
|
|
item = string_list_append(list, buf);
|
|
|
|
|
|
|
|
|
|
buf = np + (*np == '\n');
|
|
|
|
|
*np = '\0';
|
|
|
|
|
cp = sq_dequote(cp);
|
|
|
|
|
if (!cp)
|
|
|
|
|
return error(_("unable to dequote value of '%s'"),
|
|
|
|
|
item->string);
|
|
|
|
|
item->util = xstrdup(cp);
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2018-08-07 17:34:52 +08:00
|
|
|
|
2018-10-31 18:15:55 +08:00
|
|
|
/**
|
|
|
|
|
* Reads and parses the state directory's "author-script" file, and sets name,
|
|
|
|
|
* email and date accordingly.
|
|
|
|
|
* Returns 0 on success, -1 if the file could not be parsed.
|
|
|
|
|
*
|
|
|
|
|
* The author script is of the format:
|
|
|
|
|
*
|
|
|
|
|
* GIT_AUTHOR_NAME='$author_name'
|
|
|
|
|
* GIT_AUTHOR_EMAIL='$author_email'
|
|
|
|
|
* GIT_AUTHOR_DATE='$author_date'
|
|
|
|
|
*
|
|
|
|
|
* where $author_name, $author_email and $author_date are quoted. We are strict
|
2019-05-14 19:22:33 +08:00
|
|
|
* with our parsing, as the file was meant to be eval'd in the now-removed
|
2018-10-31 18:15:55 +08:00
|
|
|
* git-am.sh/git-rebase--interactive.sh scripts, and thus if the file differs
|
|
|
|
|
* from what this function expects, it is better to bail out than to do
|
|
|
|
|
* something that the user does not expect.
|
2018-08-07 17:34:52 +08:00
|
|
|
*/
|
2018-10-31 18:15:55 +08:00
|
|
|
int read_author_script(const char *path, char **name, char **email, char **date,
|
|
|
|
|
int allow_missing)
|
2018-08-07 17:34:52 +08:00
|
|
|
{
|
2018-10-31 18:15:55 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
struct string_list kv = STRING_LIST_INIT_DUP;
|
|
|
|
|
int retval = -1; /* assume failure */
|
|
|
|
|
int i, name_i = -2, email_i = -2, date_i = -2, err = 0;
|
2018-08-07 17:34:52 +08:00
|
|
|
|
2018-10-31 18:15:55 +08:00
|
|
|
if (strbuf_read_file(&buf, path, 256) <= 0) {
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
if (errno == ENOENT && allow_missing)
|
|
|
|
|
return 0;
|
|
|
|
|
else
|
|
|
|
|
return error_errno(_("could not open '%s' for reading"),
|
|
|
|
|
path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (parse_key_value_squoted(buf.buf, &kv))
|
|
|
|
|
goto finish;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < kv.nr; i++) {
|
|
|
|
|
if (!strcmp(kv.items[i].string, "GIT_AUTHOR_NAME")) {
|
|
|
|
|
if (name_i != -2)
|
|
|
|
|
name_i = error(_("'GIT_AUTHOR_NAME' already given"));
|
|
|
|
|
else
|
|
|
|
|
name_i = i;
|
|
|
|
|
} else if (!strcmp(kv.items[i].string, "GIT_AUTHOR_EMAIL")) {
|
|
|
|
|
if (email_i != -2)
|
|
|
|
|
email_i = error(_("'GIT_AUTHOR_EMAIL' already given"));
|
|
|
|
|
else
|
|
|
|
|
email_i = i;
|
|
|
|
|
} else if (!strcmp(kv.items[i].string, "GIT_AUTHOR_DATE")) {
|
|
|
|
|
if (date_i != -2)
|
|
|
|
|
date_i = error(_("'GIT_AUTHOR_DATE' already given"));
|
|
|
|
|
else
|
|
|
|
|
date_i = i;
|
|
|
|
|
} else {
|
|
|
|
|
err = error(_("unknown variable '%s'"),
|
|
|
|
|
kv.items[i].string);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (name_i == -2)
|
|
|
|
|
error(_("missing 'GIT_AUTHOR_NAME'"));
|
|
|
|
|
if (email_i == -2)
|
|
|
|
|
error(_("missing 'GIT_AUTHOR_EMAIL'"));
|
|
|
|
|
if (date_i == -2)
|
|
|
|
|
error(_("missing 'GIT_AUTHOR_DATE'"));
|
|
|
|
|
if (date_i < 0 || email_i < 0 || date_i < 0 || err)
|
|
|
|
|
goto finish;
|
|
|
|
|
*name = kv.items[name_i].util;
|
|
|
|
|
*email = kv.items[email_i].util;
|
|
|
|
|
*date = kv.items[date_i].util;
|
|
|
|
|
retval = 0;
|
|
|
|
|
finish:
|
|
|
|
|
string_list_clear(&kv, !!retval);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
return retval;
|
2018-08-07 17:34:52 +08:00
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:25:04 +08:00
|
|
|
/*
|
2018-10-31 18:15:56 +08:00
|
|
|
* Read a GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL AND GIT_AUTHOR_DATE from a
|
|
|
|
|
* file with shell quoting into struct argv_array. Returns -1 on
|
|
|
|
|
* error, 0 otherwise.
|
2016-10-21 20:25:04 +08:00
|
|
|
*/
|
2017-01-02 23:35:25 +08:00
|
|
|
static int read_env_script(struct argv_array *env)
|
2016-10-21 20:25:04 +08:00
|
|
|
{
|
2018-10-31 18:15:56 +08:00
|
|
|
char *name, *email, *date;
|
2016-10-21 20:25:04 +08:00
|
|
|
|
2018-10-31 18:15:56 +08:00
|
|
|
if (read_author_script(rebase_path_author_script(),
|
|
|
|
|
&name, &email, &date, 0))
|
2017-01-02 23:35:25 +08:00
|
|
|
return -1;
|
2016-10-21 20:25:04 +08:00
|
|
|
|
2018-10-31 18:15:56 +08:00
|
|
|
argv_array_pushf(env, "GIT_AUTHOR_NAME=%s", name);
|
|
|
|
|
argv_array_pushf(env, "GIT_AUTHOR_EMAIL=%s", email);
|
|
|
|
|
argv_array_pushf(env, "GIT_AUTHOR_DATE=%s", date);
|
|
|
|
|
free(name);
|
|
|
|
|
free(email);
|
|
|
|
|
free(date);
|
2016-10-21 20:25:04 +08:00
|
|
|
|
2017-01-02 23:35:25 +08:00
|
|
|
return 0;
|
2016-10-21 20:25:04 +08:00
|
|
|
}
|
|
|
|
|
|
2017-11-24 19:07:57 +08:00
|
|
|
static char *get_author(const char *message)
|
|
|
|
|
{
|
|
|
|
|
size_t len;
|
|
|
|
|
const char *a;
|
|
|
|
|
|
|
|
|
|
a = find_commit_header(message, "author", &len);
|
|
|
|
|
if (a)
|
|
|
|
|
return xmemdupz(a, len);
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
/* Read author-script and return an ident line (author <email> timestamp) */
|
|
|
|
|
static const char *read_author_ident(struct strbuf *buf)
|
|
|
|
|
{
|
sequencer: fix "rebase -i --root" corrupting author header timestamp
When "git rebase -i --root" creates a new root commit, it corrupts the
"author" header's timestamp by prepending a "@":
author A U Thor <author@example.com> @1112912773 -0700
The commit parser is very strict about the format of the "author"
header, and does not allow a "@" in that position.
The "@" comes from GIT_AUTHOR_DATE in "rebase-merge/author-script",
signifying a Unix epoch-based timestamp, however, read_author_ident()
incorrectly allows it to slip into the commit's "author" header, thus
corrupting it.
One possible fix would be simply to filter out the "@" when constructing
the "author" header timestamp, however, a more correct fix is to parse
the GIT_AUTHOR_DATE date (via parse_date()) and format the parsed result
into the "author" header. Since "rebase-merge/author-script" may be
edited by the user, this approach has the extra benefit of catching
other potential timestamp corruption due to hand-editing.
We can do better than calling parse_date() ourselves and constructing
the "author" header manually, however, by instead taking advantage of
fmt_ident() which does this work for us.
The benefits of using fmt_ident() are twofold. First, it simplifies the
logic considerably by allowing us to avoid the complexity of building
the "author" header in parallel with and in the same buffer from which
"rebase-merge/author-script" is being parsed. Instead, fmt_ident() is
invoked to compose the header after parsing is complete.
Second, fmt_ident() is careful to prevent "crud" from polluting the
composed ident. As with validating GIT_AUTHOR_DATE, this "crud"
avoidance prevents other (possibly hand-edited) bogus author information
from "rebase-merge/author-script" from corrupting the commit object.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-31 15:33:30 +08:00
|
|
|
struct strbuf out = STRBUF_INIT;
|
2018-10-31 18:15:56 +08:00
|
|
|
char *name, *email, *date;
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
|
2018-10-31 18:15:56 +08:00
|
|
|
if (read_author_script(rebase_path_author_script(),
|
|
|
|
|
&name, &email, &date, 0))
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
2018-07-31 15:33:31 +08:00
|
|
|
/* validate date since fmt_ident() will die() on bad value */
|
2018-10-31 18:15:56 +08:00
|
|
|
if (parse_date(date, &out)){
|
2018-07-31 15:33:31 +08:00
|
|
|
warning(_("invalid date format '%s' in '%s'"),
|
2018-10-31 18:15:56 +08:00
|
|
|
date, rebase_path_author_script());
|
2018-07-31 15:33:31 +08:00
|
|
|
strbuf_release(&out);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
strbuf_reset(&out);
|
2019-02-05 02:48:50 +08:00
|
|
|
strbuf_addstr(&out, fmt_ident(name, email, WANT_AUTHOR_IDENT, date, 0));
|
sequencer: fix "rebase -i --root" corrupting author header timestamp
When "git rebase -i --root" creates a new root commit, it corrupts the
"author" header's timestamp by prepending a "@":
author A U Thor <author@example.com> @1112912773 -0700
The commit parser is very strict about the format of the "author"
header, and does not allow a "@" in that position.
The "@" comes from GIT_AUTHOR_DATE in "rebase-merge/author-script",
signifying a Unix epoch-based timestamp, however, read_author_ident()
incorrectly allows it to slip into the commit's "author" header, thus
corrupting it.
One possible fix would be simply to filter out the "@" when constructing
the "author" header timestamp, however, a more correct fix is to parse
the GIT_AUTHOR_DATE date (via parse_date()) and format the parsed result
into the "author" header. Since "rebase-merge/author-script" may be
edited by the user, this approach has the extra benefit of catching
other potential timestamp corruption due to hand-editing.
We can do better than calling parse_date() ourselves and constructing
the "author" header manually, however, by instead taking advantage of
fmt_ident() which does this work for us.
The benefits of using fmt_ident() are twofold. First, it simplifies the
logic considerably by allowing us to avoid the complexity of building
the "author" header in parallel with and in the same buffer from which
"rebase-merge/author-script" is being parsed. Instead, fmt_ident() is
invoked to compose the header after parsing is complete.
Second, fmt_ident() is careful to prevent "crud" from polluting the
composed ident. As with validating GIT_AUTHOR_DATE, this "crud"
avoidance prevents other (possibly hand-edited) bogus author information
from "rebase-merge/author-script" from corrupting the commit object.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-31 15:33:30 +08:00
|
|
|
strbuf_swap(buf, &out);
|
|
|
|
|
strbuf_release(&out);
|
2018-10-31 18:15:56 +08:00
|
|
|
free(name);
|
|
|
|
|
free(email);
|
|
|
|
|
free(date);
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
return buf->buf;
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:26:32 +08:00
|
|
|
static const char staged_changes_advice[] =
|
|
|
|
|
N_("you have staged changes in your working tree\n"
|
|
|
|
|
"If these changes are meant to be squashed into the previous commit, run:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git commit --amend %s\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"If they are meant to go into a new commit, run:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git commit %s\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"In both cases, once you're done, continue with:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git rebase --continue\n");
|
|
|
|
|
|
2017-03-24 00:07:11 +08:00
|
|
|
#define ALLOW_EMPTY (1<<0)
|
|
|
|
|
#define EDIT_MSG (1<<1)
|
|
|
|
|
#define AMEND_MSG (1<<2)
|
|
|
|
|
#define CLEANUP_MSG (1<<3)
|
2017-03-24 00:07:17 +08:00
|
|
|
#define VERIFY_MSG (1<<4)
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
#define CREATE_ROOT_COMMIT (1<<5)
|
2017-03-24 00:07:11 +08:00
|
|
|
|
2018-08-11 00:51:32 +08:00
|
|
|
static int run_command_silent_on_success(struct child_process *cmd)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
cmd->stdout_to_stderr = 1;
|
|
|
|
|
rc = pipe_command(cmd,
|
|
|
|
|
NULL, 0,
|
|
|
|
|
NULL, 0,
|
|
|
|
|
&buf, 0);
|
|
|
|
|
|
|
|
|
|
if (rc)
|
|
|
|
|
fputs(buf.buf, stderr);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
/*
|
|
|
|
|
* If we are cherry-pick, and if the merge did not result in
|
|
|
|
|
* hand-editing, we will hit this commit and inherit the original
|
|
|
|
|
* author date and name.
|
2016-10-21 20:25:04 +08:00
|
|
|
*
|
2012-01-12 02:15:57 +08:00
|
|
|
* If we are revert, or if our cherry-pick results in a hand merge,
|
|
|
|
|
* we had better say that the current user is responsible for that.
|
2016-10-21 20:25:04 +08:00
|
|
|
*
|
|
|
|
|
* An exception is when run_git_commit() is called during an
|
|
|
|
|
* interactive rebase: in that case, we will want to retain the
|
|
|
|
|
* author metadata.
|
2012-01-12 02:15:57 +08:00
|
|
|
*/
|
2018-11-10 13:48:56 +08:00
|
|
|
static int run_git_commit(struct repository *r,
|
|
|
|
|
const char *defmsg,
|
|
|
|
|
struct replay_opts *opts,
|
2017-03-24 00:07:11 +08:00
|
|
|
unsigned int flags)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2017-01-02 23:35:29 +08:00
|
|
|
struct child_process cmd = CHILD_PROCESS_INIT;
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
|
2018-06-17 03:00:38 +08:00
|
|
|
if ((flags & CREATE_ROOT_COMMIT) && !(flags & AMEND_MSG)) {
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
struct strbuf msg = STRBUF_INIT, script = STRBUF_INIT;
|
2018-08-07 17:34:51 +08:00
|
|
|
const char *author = NULL;
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
struct object_id root_commit, *cache_tree_oid;
|
|
|
|
|
int res = 0;
|
|
|
|
|
|
2018-08-07 17:34:51 +08:00
|
|
|
if (is_rebase_i(opts)) {
|
|
|
|
|
author = read_author_ident(&script);
|
|
|
|
|
if (!author) {
|
|
|
|
|
strbuf_release(&script);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
if (!defmsg)
|
|
|
|
|
BUG("root commit without message");
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (!(cache_tree_oid = get_cache_tree_oid(r->index)))
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
res = -1;
|
|
|
|
|
|
|
|
|
|
if (!res)
|
|
|
|
|
res = strbuf_read_file(&msg, defmsg, 0);
|
|
|
|
|
|
|
|
|
|
if (res <= 0)
|
|
|
|
|
res = error_errno(_("could not read '%s'"), defmsg);
|
|
|
|
|
else
|
|
|
|
|
res = commit_tree(msg.buf, msg.len, cache_tree_oid,
|
|
|
|
|
NULL, &root_commit, author,
|
|
|
|
|
opts->gpg_sign);
|
|
|
|
|
|
|
|
|
|
strbuf_release(&msg);
|
|
|
|
|
strbuf_release(&script);
|
|
|
|
|
if (!res) {
|
|
|
|
|
update_ref(NULL, "CHERRY_PICK_HEAD", &root_commit, NULL,
|
|
|
|
|
REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR);
|
|
|
|
|
res = update_ref(NULL, "HEAD", &root_commit, NULL, 0,
|
|
|
|
|
UPDATE_REFS_MSG_ON_ERR);
|
|
|
|
|
}
|
|
|
|
|
return res < 0 ? error(_("writing root commit")) : 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:35:29 +08:00
|
|
|
cmd.git_cmd = 1;
|
|
|
|
|
|
2018-08-11 00:51:32 +08:00
|
|
|
if (is_rebase_i(opts) && read_env_script(&cmd.env_array)) {
|
|
|
|
|
const char *gpg_opt = gpg_sign_opt_quoted(opts);
|
2016-10-21 20:25:12 +08:00
|
|
|
|
2018-08-11 00:51:32 +08:00
|
|
|
return error(_(staged_changes_advice),
|
|
|
|
|
gpg_opt, gpg_opt);
|
2016-10-21 20:25:04 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_push(&cmd.args, "commit");
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2017-03-24 00:07:17 +08:00
|
|
|
if (!(flags & VERIFY_MSG))
|
|
|
|
|
argv_array_push(&cmd.args, "-n");
|
2017-03-24 00:07:11 +08:00
|
|
|
if ((flags & AMEND_MSG))
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_push(&cmd.args, "--amend");
|
2014-06-20 05:28:20 +08:00
|
|
|
if (opts->gpg_sign)
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_pushf(&cmd.args, "-S%s", opts->gpg_sign);
|
2016-10-21 20:25:04 +08:00
|
|
|
if (defmsg)
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_pushl(&cmd.args, "-F", defmsg, NULL);
|
2018-04-28 04:48:28 +08:00
|
|
|
else if (!(flags & EDIT_MSG))
|
|
|
|
|
argv_array_pushl(&cmd.args, "-C", "HEAD", NULL);
|
2017-03-24 00:07:11 +08:00
|
|
|
if ((flags & CLEANUP_MSG))
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_push(&cmd.args, "--cleanup=strip");
|
2017-03-24 00:07:11 +08:00
|
|
|
if ((flags & EDIT_MSG))
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_push(&cmd.args, "-e");
|
2017-03-24 00:07:11 +08:00
|
|
|
else if (!(flags & CLEANUP_MSG) &&
|
2016-10-21 20:25:28 +08:00
|
|
|
!opts->signoff && !opts->record_origin &&
|
2019-04-17 18:23:30 +08:00
|
|
|
!opts->explicit_cleanup)
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_push(&cmd.args, "--cleanup=verbatim");
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
|
2017-03-24 00:07:11 +08:00
|
|
|
if ((flags & ALLOW_EMPTY))
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_push(&cmd.args, "--allow-empty");
|
2012-04-12 04:21:53 +08:00
|
|
|
|
sequencer: fix --allow-empty-message behavior, make it smarter
In commit b00bf1c9a8dd ("git-rebase: make --allow-empty-message the
default", 2018-06-27), several arguments were given for transplanting
empty commits without halting and asking the user for confirmation on
each commit. These arguments were incomplete because the logic clearly
assumed the only cases under consideration were transplanting of commits
with empty messages (see the comment about "There are two sources for
commits with empty messages). It didn't discuss or even consider
rewords, squashes, etc. where the user is explicitly asked for a new
commit message and provides an empty one. (My bad, I totally should
have thought about that at the time, but just didn't.)
Rewords and squashes are significantly different, though, as described
by SZEDER:
Let's suppose you start an interactive rebase, choose a commit to
squash, save the instruction sheet, rebase fires up your editor, and
then you notice that you mistakenly chose the wrong commit to
squash. What do you do, how do you abort?
Before [that commit] you could clear the commit message, exit the
editor, and then rebase would say "Aborting commit due to empty
commit message.", and you get to run 'git rebase --abort', and start
over.
But [since that commit, ...] saving the commit message as is would
let rebase continue and create a bunch of unnecessary objects, and
then you would have to use the reflog to return to the pre-rebase
state.
Also, he states:
The instructions in the commit message template, which is shown for
'reword' and 'squash', too, still say...
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
These are sound arguments that when editing commit messages during a
sequencer operation, that if the commit message is empty then the
operation should halt and ask the user to correct. The arguments in
commit b00bf1c9a8dd (referenced above) still apply when transplanting
previously created commits with empty commit messages, so the sequencer
should not halt for those.
Furthermore, all rationale so far applies equally for cherry-pick as for
rebase. Therefore, make the code default to --allow-empty-message when
transplanting an existing commit, and to default to halting when the
user is asked to edit a commit message and provides an empty one -- for
both rebase and cherry-pick.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:18:48 +08:00
|
|
|
if (!(flags & EDIT_MSG))
|
2017-01-02 23:35:29 +08:00
|
|
|
argv_array_push(&cmd.args, "--allow-empty-message");
|
2012-08-02 18:38:51 +08:00
|
|
|
|
2018-08-11 00:51:32 +08:00
|
|
|
if (is_rebase_i(opts) && !(flags & EDIT_MSG))
|
|
|
|
|
return run_command_silent_on_success(&cmd);
|
|
|
|
|
else
|
|
|
|
|
return run_command(&cmd);
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
}
|
|
|
|
|
|
2017-11-10 19:09:42 +08:00
|
|
|
static int rest_is_empty(const struct strbuf *sb, int start)
|
|
|
|
|
{
|
|
|
|
|
int i, eol;
|
|
|
|
|
const char *nl;
|
|
|
|
|
|
|
|
|
|
/* Check if the rest is just whitespace and Signed-off-by's. */
|
|
|
|
|
for (i = start; i < sb->len; i++) {
|
|
|
|
|
nl = memchr(sb->buf + i, '\n', sb->len - i);
|
|
|
|
|
if (nl)
|
|
|
|
|
eol = nl - sb->buf;
|
|
|
|
|
else
|
|
|
|
|
eol = sb->len;
|
|
|
|
|
|
|
|
|
|
if (strlen(sign_off_header) <= eol - i &&
|
|
|
|
|
starts_with(sb->buf + i, sign_off_header)) {
|
|
|
|
|
i = eol;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
while (i < eol)
|
|
|
|
|
if (!isspace(sb->buf[i++]))
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-17 18:23:25 +08:00
|
|
|
void cleanup_message(struct strbuf *msgbuf,
|
|
|
|
|
enum commit_msg_cleanup_mode cleanup_mode, int verbose)
|
|
|
|
|
{
|
|
|
|
|
if (verbose || /* Truncate the message just before the diff, if any. */
|
|
|
|
|
cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS)
|
|
|
|
|
strbuf_setlen(msgbuf, wt_status_locate_end(msgbuf->buf, msgbuf->len));
|
|
|
|
|
if (cleanup_mode != COMMIT_MSG_CLEANUP_NONE)
|
|
|
|
|
strbuf_stripspace(msgbuf, cleanup_mode == COMMIT_MSG_CLEANUP_ALL);
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-10 19:09:42 +08:00
|
|
|
/*
|
|
|
|
|
* Find out if the message in the strbuf contains only whitespace and
|
|
|
|
|
* Signed-off-by lines.
|
|
|
|
|
*/
|
|
|
|
|
int message_is_empty(const struct strbuf *sb,
|
|
|
|
|
enum commit_msg_cleanup_mode cleanup_mode)
|
|
|
|
|
{
|
|
|
|
|
if (cleanup_mode == COMMIT_MSG_CLEANUP_NONE && sb->len)
|
|
|
|
|
return 0;
|
|
|
|
|
return rest_is_empty(sb, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* See if the user edited the message in the editor or left what
|
|
|
|
|
* was in the template intact
|
|
|
|
|
*/
|
|
|
|
|
int template_untouched(const struct strbuf *sb, const char *template_file,
|
|
|
|
|
enum commit_msg_cleanup_mode cleanup_mode)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf tmpl = STRBUF_INIT;
|
|
|
|
|
const char *start;
|
|
|
|
|
|
|
|
|
|
if (cleanup_mode == COMMIT_MSG_CLEANUP_NONE && sb->len)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
if (!template_file || strbuf_read_file(&tmpl, template_file, 0) <= 0)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
strbuf_stripspace(&tmpl, cleanup_mode == COMMIT_MSG_CLEANUP_ALL);
|
|
|
|
|
if (!skip_prefix(sb->buf, tmpl.buf, &start))
|
|
|
|
|
start = sb->buf;
|
|
|
|
|
strbuf_release(&tmpl);
|
|
|
|
|
return rest_is_empty(sb, start - sb->buf);
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-17 19:34:47 +08:00
|
|
|
int update_head_with_reflog(const struct commit *old_head,
|
|
|
|
|
const struct object_id *new_head,
|
|
|
|
|
const char *action, const struct strbuf *msg,
|
|
|
|
|
struct strbuf *err)
|
|
|
|
|
{
|
|
|
|
|
struct ref_transaction *transaction;
|
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
const char *nl;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
if (action) {
|
|
|
|
|
strbuf_addstr(&sb, action);
|
|
|
|
|
strbuf_addstr(&sb, ": ");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nl = strchr(msg->buf, '\n');
|
|
|
|
|
if (nl) {
|
|
|
|
|
strbuf_add(&sb, msg->buf, nl + 1 - msg->buf);
|
|
|
|
|
} else {
|
|
|
|
|
strbuf_addbuf(&sb, msg);
|
|
|
|
|
strbuf_addch(&sb, '\n');
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
transaction = ref_transaction_begin(err);
|
|
|
|
|
if (!transaction ||
|
|
|
|
|
ref_transaction_update(transaction, "HEAD", new_head,
|
|
|
|
|
old_head ? &old_head->object.oid : &null_oid,
|
|
|
|
|
0, sb.buf, err) ||
|
|
|
|
|
ref_transaction_commit(transaction, err)) {
|
|
|
|
|
ret = -1;
|
|
|
|
|
}
|
|
|
|
|
ref_transaction_free(transaction);
|
|
|
|
|
strbuf_release(&sb);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-17 19:34:48 +08:00
|
|
|
static int run_rewrite_hook(const struct object_id *oldoid,
|
|
|
|
|
const struct object_id *newoid)
|
|
|
|
|
{
|
|
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
|
|
|
|
const char *argv[3];
|
|
|
|
|
int code;
|
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
argv[0] = find_hook("post-rewrite");
|
|
|
|
|
if (!argv[0])
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
argv[1] = "amend";
|
|
|
|
|
argv[2] = NULL;
|
|
|
|
|
|
|
|
|
|
proc.argv = argv;
|
|
|
|
|
proc.in = -1;
|
|
|
|
|
proc.stdout_to_stderr = 1;
|
2019-02-23 06:25:06 +08:00
|
|
|
proc.trace2_hook_name = "post-rewrite";
|
2017-11-17 19:34:48 +08:00
|
|
|
|
|
|
|
|
code = start_command(&proc);
|
|
|
|
|
if (code)
|
|
|
|
|
return code;
|
|
|
|
|
strbuf_addf(&sb, "%s %s\n", oid_to_hex(oldoid), oid_to_hex(newoid));
|
|
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
|
|
|
|
write_in_full(proc.in, sb.buf, sb.len);
|
|
|
|
|
close(proc.in);
|
|
|
|
|
strbuf_release(&sb);
|
|
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
return finish_command(&proc);
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-12 10:13:23 +08:00
|
|
|
void commit_post_rewrite(struct repository *r,
|
|
|
|
|
const struct commit *old_head,
|
2017-11-17 19:34:48 +08:00
|
|
|
const struct object_id *new_head)
|
|
|
|
|
{
|
|
|
|
|
struct notes_rewrite_cfg *cfg;
|
|
|
|
|
|
|
|
|
|
cfg = init_copy_notes_for_rewrite("amend");
|
|
|
|
|
if (cfg) {
|
|
|
|
|
/* we are amending, so old_head is not NULL */
|
|
|
|
|
copy_note_for_rewrite(cfg, &old_head->object.oid, new_head);
|
2019-01-12 10:13:23 +08:00
|
|
|
finish_copy_notes_for_rewrite(r, cfg, "Notes added by 'git commit --amend'");
|
2017-11-17 19:34:48 +08:00
|
|
|
}
|
|
|
|
|
run_rewrite_hook(&old_head->object.oid, new_head);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int run_prepare_commit_msg_hook(struct repository *r,
|
|
|
|
|
struct strbuf *msg,
|
|
|
|
|
const char *commit)
|
2018-01-24 20:34:22 +08:00
|
|
|
{
|
|
|
|
|
struct argv_array hook_env = ARGV_ARRAY_INIT;
|
|
|
|
|
int ret;
|
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
|
|
name = git_path_commit_editmsg();
|
|
|
|
|
if (write_message(msg->buf, msg->len, name, 0))
|
|
|
|
|
return -1;
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
argv_array_pushf(&hook_env, "GIT_INDEX_FILE=%s", r->index_file);
|
2018-01-24 20:34:22 +08:00
|
|
|
argv_array_push(&hook_env, "GIT_EDITOR=:");
|
|
|
|
|
if (commit)
|
|
|
|
|
ret = run_hook_le(hook_env.argv, "prepare-commit-msg", name,
|
|
|
|
|
"commit", commit, NULL);
|
|
|
|
|
else
|
|
|
|
|
ret = run_hook_le(hook_env.argv, "prepare-commit-msg", name,
|
|
|
|
|
"message", NULL);
|
|
|
|
|
if (ret)
|
|
|
|
|
ret = error(_("'prepare-commit-msg' hook failed"));
|
|
|
|
|
argv_array_clear(&hook_env);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-24 19:07:54 +08:00
|
|
|
static const char implicit_ident_advice_noconfig[] =
|
|
|
|
|
N_("Your name and email address were configured automatically based\n"
|
|
|
|
|
"on your username and hostname. Please check that they are accurate.\n"
|
|
|
|
|
"You can suppress this message by setting them explicitly. Run the\n"
|
|
|
|
|
"following command and follow the instructions in your editor to edit\n"
|
|
|
|
|
"your configuration file:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git config --global --edit\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"After doing this, you may fix the identity used for this commit with:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git commit --amend --reset-author\n");
|
|
|
|
|
|
|
|
|
|
static const char implicit_ident_advice_config[] =
|
|
|
|
|
N_("Your name and email address were configured automatically based\n"
|
|
|
|
|
"on your username and hostname. Please check that they are accurate.\n"
|
|
|
|
|
"You can suppress this message by setting them explicitly:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git config --global user.name \"Your Name\"\n"
|
|
|
|
|
" git config --global user.email you@example.com\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"After doing this, you may fix the identity used for this commit with:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git commit --amend --reset-author\n");
|
|
|
|
|
|
|
|
|
|
static const char *implicit_ident_advice(void)
|
|
|
|
|
{
|
|
|
|
|
char *user_config = expand_user_path("~/.gitconfig", 0);
|
|
|
|
|
char *xdg_config = xdg_config_home("config");
|
|
|
|
|
int config_exists = file_exists(user_config) || file_exists(xdg_config);
|
|
|
|
|
|
|
|
|
|
free(user_config);
|
|
|
|
|
free(xdg_config);
|
|
|
|
|
|
|
|
|
|
if (config_exists)
|
|
|
|
|
return _(implicit_ident_advice_config);
|
|
|
|
|
else
|
|
|
|
|
return _(implicit_ident_advice_noconfig);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
void print_commit_summary(struct repository *r,
|
|
|
|
|
const char *prefix,
|
|
|
|
|
const struct object_id *oid,
|
2017-11-24 19:07:54 +08:00
|
|
|
unsigned int flags)
|
|
|
|
|
{
|
|
|
|
|
struct rev_info rev;
|
|
|
|
|
struct commit *commit;
|
|
|
|
|
struct strbuf format = STRBUF_INIT;
|
|
|
|
|
const char *head;
|
|
|
|
|
struct pretty_print_context pctx = {0};
|
|
|
|
|
struct strbuf author_ident = STRBUF_INIT;
|
|
|
|
|
struct strbuf committer_ident = STRBUF_INIT;
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
commit = lookup_commit(r, oid);
|
2017-11-24 19:07:54 +08:00
|
|
|
if (!commit)
|
|
|
|
|
die(_("couldn't look up newly created commit"));
|
|
|
|
|
if (parse_commit(commit))
|
|
|
|
|
die(_("could not parse newly created commit"));
|
|
|
|
|
|
|
|
|
|
strbuf_addstr(&format, "format:%h] %s");
|
|
|
|
|
|
|
|
|
|
format_commit_message(commit, "%an <%ae>", &author_ident, &pctx);
|
|
|
|
|
format_commit_message(commit, "%cn <%ce>", &committer_ident, &pctx);
|
|
|
|
|
if (strbuf_cmp(&author_ident, &committer_ident)) {
|
|
|
|
|
strbuf_addstr(&format, "\n Author: ");
|
|
|
|
|
strbuf_addbuf_percentquote(&format, &author_ident);
|
|
|
|
|
}
|
|
|
|
|
if (flags & SUMMARY_SHOW_AUTHOR_DATE) {
|
|
|
|
|
struct strbuf date = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
format_commit_message(commit, "%ad", &date, &pctx);
|
|
|
|
|
strbuf_addstr(&format, "\n Date: ");
|
|
|
|
|
strbuf_addbuf_percentquote(&format, &date);
|
|
|
|
|
strbuf_release(&date);
|
|
|
|
|
}
|
|
|
|
|
if (!committer_ident_sufficiently_given()) {
|
|
|
|
|
strbuf_addstr(&format, "\n Committer: ");
|
|
|
|
|
strbuf_addbuf_percentquote(&format, &committer_ident);
|
|
|
|
|
if (advice_implicit_identity) {
|
|
|
|
|
strbuf_addch(&format, '\n');
|
|
|
|
|
strbuf_addstr(&format, implicit_ident_advice());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
strbuf_release(&author_ident);
|
|
|
|
|
strbuf_release(&committer_ident);
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
repo_init_revisions(r, &rev, prefix);
|
2017-11-24 19:07:54 +08:00
|
|
|
setup_revisions(0, NULL, &rev, NULL);
|
|
|
|
|
|
|
|
|
|
rev.diff = 1;
|
|
|
|
|
rev.diffopt.output_format =
|
|
|
|
|
DIFF_FORMAT_SHORTSTAT | DIFF_FORMAT_SUMMARY;
|
|
|
|
|
|
|
|
|
|
rev.verbose_header = 1;
|
|
|
|
|
rev.show_root_diff = 1;
|
|
|
|
|
get_commit_format(format.buf, &rev);
|
|
|
|
|
rev.always_show_header = 0;
|
2018-02-14 05:39:15 +08:00
|
|
|
rev.diffopt.detect_rename = DIFF_DETECT_RENAME;
|
2017-11-24 19:07:54 +08:00
|
|
|
rev.diffopt.break_opt = 0;
|
|
|
|
|
diff_setup_done(&rev.diffopt);
|
|
|
|
|
|
|
|
|
|
head = resolve_ref_unsafe("HEAD", 0, NULL, NULL);
|
|
|
|
|
if (!head)
|
|
|
|
|
die_errno(_("unable to resolve HEAD after creating commit"));
|
|
|
|
|
if (!strcmp(head, "HEAD"))
|
|
|
|
|
head = _("detached HEAD");
|
|
|
|
|
else
|
|
|
|
|
skip_prefix(head, "refs/heads/", &head);
|
|
|
|
|
printf("[%s%s ", head, (flags & SUMMARY_INITIAL_COMMIT) ?
|
|
|
|
|
_(" (root-commit)") : "");
|
|
|
|
|
|
|
|
|
|
if (!log_tree_commit(&rev, commit)) {
|
|
|
|
|
rev.always_show_header = 1;
|
|
|
|
|
rev.use_terminator = 1;
|
|
|
|
|
log_tree_commit(&rev, commit);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
strbuf_release(&format);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int parse_head(struct repository *r, struct commit **head)
|
2017-11-24 19:07:57 +08:00
|
|
|
{
|
|
|
|
|
struct commit *current_head;
|
|
|
|
|
struct object_id oid;
|
|
|
|
|
|
|
|
|
|
if (get_oid("HEAD", &oid)) {
|
|
|
|
|
current_head = NULL;
|
|
|
|
|
} else {
|
2018-11-10 13:48:57 +08:00
|
|
|
current_head = lookup_commit_reference(r, &oid);
|
2017-11-24 19:07:57 +08:00
|
|
|
if (!current_head)
|
|
|
|
|
return error(_("could not parse HEAD"));
|
2018-08-29 05:22:48 +08:00
|
|
|
if (!oideq(&oid, ¤t_head->object.oid)) {
|
2017-11-24 19:07:57 +08:00
|
|
|
warning(_("HEAD %s is not a commit!"),
|
|
|
|
|
oid_to_hex(&oid));
|
|
|
|
|
}
|
|
|
|
|
if (parse_commit(current_head))
|
|
|
|
|
return error(_("could not parse HEAD commit"));
|
|
|
|
|
}
|
|
|
|
|
*head = current_head;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Try to commit without forking 'git commit'. In some cases we need
|
|
|
|
|
* to run 'git commit' to display an error message
|
|
|
|
|
*
|
|
|
|
|
* Returns:
|
|
|
|
|
* -1 - error unable to commit
|
|
|
|
|
* 0 - success
|
|
|
|
|
* 1 - run 'git commit'
|
|
|
|
|
*/
|
2018-11-10 13:48:56 +08:00
|
|
|
static int try_to_commit(struct repository *r,
|
|
|
|
|
struct strbuf *msg, const char *author,
|
2017-11-24 19:07:57 +08:00
|
|
|
struct replay_opts *opts, unsigned int flags,
|
|
|
|
|
struct object_id *oid)
|
|
|
|
|
{
|
|
|
|
|
struct object_id tree;
|
|
|
|
|
struct commit *current_head;
|
|
|
|
|
struct commit_list *parents = NULL;
|
|
|
|
|
struct commit_extra_header *extra = NULL;
|
|
|
|
|
struct strbuf err = STRBUF_INIT;
|
2018-01-24 20:34:22 +08:00
|
|
|
struct strbuf commit_msg = STRBUF_INIT;
|
2017-11-24 19:07:57 +08:00
|
|
|
char *amend_author = NULL;
|
2018-01-24 20:34:22 +08:00
|
|
|
const char *hook_commit = NULL;
|
2017-11-24 19:07:57 +08:00
|
|
|
enum commit_msg_cleanup_mode cleanup;
|
|
|
|
|
int res = 0;
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
if (parse_head(r, ¤t_head))
|
2017-11-24 19:07:57 +08:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
if (flags & AMEND_MSG) {
|
|
|
|
|
const char *exclude_gpgsig[] = { "gpgsig", NULL };
|
|
|
|
|
const char *out_enc = get_commit_output_encoding();
|
|
|
|
|
const char *message = logmsg_reencode(current_head, NULL,
|
|
|
|
|
out_enc);
|
|
|
|
|
|
|
|
|
|
if (!msg) {
|
|
|
|
|
const char *orig_message = NULL;
|
|
|
|
|
|
|
|
|
|
find_commit_subject(message, &orig_message);
|
2018-01-24 20:34:22 +08:00
|
|
|
msg = &commit_msg;
|
2017-11-24 19:07:57 +08:00
|
|
|
strbuf_addstr(msg, orig_message);
|
2018-01-24 20:34:22 +08:00
|
|
|
hook_commit = "HEAD";
|
2017-11-24 19:07:57 +08:00
|
|
|
}
|
|
|
|
|
author = amend_author = get_author(message);
|
|
|
|
|
unuse_commit_buffer(current_head, message);
|
|
|
|
|
if (!author) {
|
|
|
|
|
res = error(_("unable to parse commit author"));
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
parents = copy_commit_list(current_head->parents);
|
|
|
|
|
extra = read_commit_extra_headers(current_head, exclude_gpgsig);
|
|
|
|
|
} else if (current_head) {
|
|
|
|
|
commit_list_insert(current_head, &parents);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (write_index_as_tree(&tree, r->index, r->index_file, 0, NULL)) {
|
2017-11-24 19:07:57 +08:00
|
|
|
res = error(_("git write-tree failed to write a tree"));
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
if (!(flags & ALLOW_EMPTY) && oideq(current_head ?
|
|
|
|
|
get_commit_tree_oid(current_head) :
|
|
|
|
|
the_hash_algo->empty_tree, &tree)) {
|
2017-11-24 19:07:57 +08:00
|
|
|
res = 1; /* run 'git commit' to display error message */
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-24 20:34:22 +08:00
|
|
|
if (find_hook("prepare-commit-msg")) {
|
2018-11-10 13:48:56 +08:00
|
|
|
res = run_prepare_commit_msg_hook(r, msg, hook_commit);
|
2018-01-24 20:34:22 +08:00
|
|
|
if (res)
|
|
|
|
|
goto out;
|
|
|
|
|
if (strbuf_read_file(&commit_msg, git_path_commit_editmsg(),
|
|
|
|
|
2048) < 0) {
|
|
|
|
|
res = error_errno(_("unable to read commit message "
|
|
|
|
|
"from '%s'"),
|
|
|
|
|
git_path_commit_editmsg());
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
msg = &commit_msg;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-29 19:08:42 +08:00
|
|
|
if (flags & CLEANUP_MSG)
|
|
|
|
|
cleanup = COMMIT_MSG_CLEANUP_ALL;
|
|
|
|
|
else if ((opts->signoff || opts->record_origin) &&
|
|
|
|
|
!opts->explicit_cleanup)
|
|
|
|
|
cleanup = COMMIT_MSG_CLEANUP_SPACE;
|
|
|
|
|
else
|
|
|
|
|
cleanup = opts->default_msg_cleanup;
|
2018-01-24 20:34:22 +08:00
|
|
|
|
|
|
|
|
if (cleanup != COMMIT_MSG_CLEANUP_NONE)
|
|
|
|
|
strbuf_stripspace(msg, cleanup == COMMIT_MSG_CLEANUP_ALL);
|
sequencer: fix --allow-empty-message behavior, make it smarter
In commit b00bf1c9a8dd ("git-rebase: make --allow-empty-message the
default", 2018-06-27), several arguments were given for transplanting
empty commits without halting and asking the user for confirmation on
each commit. These arguments were incomplete because the logic clearly
assumed the only cases under consideration were transplanting of commits
with empty messages (see the comment about "There are two sources for
commits with empty messages). It didn't discuss or even consider
rewords, squashes, etc. where the user is explicitly asked for a new
commit message and provides an empty one. (My bad, I totally should
have thought about that at the time, but just didn't.)
Rewords and squashes are significantly different, though, as described
by SZEDER:
Let's suppose you start an interactive rebase, choose a commit to
squash, save the instruction sheet, rebase fires up your editor, and
then you notice that you mistakenly chose the wrong commit to
squash. What do you do, how do you abort?
Before [that commit] you could clear the commit message, exit the
editor, and then rebase would say "Aborting commit due to empty
commit message.", and you get to run 'git rebase --abort', and start
over.
But [since that commit, ...] saving the commit message as is would
let rebase continue and create a bunch of unnecessary objects, and
then you would have to use the reflog to return to the pre-rebase
state.
Also, he states:
The instructions in the commit message template, which is shown for
'reword' and 'squash', too, still say...
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
These are sound arguments that when editing commit messages during a
sequencer operation, that if the commit message is empty then the
operation should halt and ask the user to correct. The arguments in
commit b00bf1c9a8dd (referenced above) still apply when transplanting
previously created commits with empty commit messages, so the sequencer
should not halt for those.
Furthermore, all rationale so far applies equally for cherry-pick as for
rebase. Therefore, make the code default to --allow-empty-message when
transplanting an existing commit, and to default to halting when the
user is asked to edit a commit message and provides an empty one -- for
both rebase and cherry-pick.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:18:48 +08:00
|
|
|
if ((flags & EDIT_MSG) && message_is_empty(msg, cleanup)) {
|
2018-01-24 20:34:22 +08:00
|
|
|
res = 1; /* run 'git commit' to display error message */
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-19 02:15:04 +08:00
|
|
|
reset_ident_date();
|
|
|
|
|
|
2018-02-16 06:55:43 +08:00
|
|
|
if (commit_tree_extended(msg->buf, msg->len, &tree, parents,
|
|
|
|
|
oid, author, opts->gpg_sign, extra)) {
|
2017-11-24 19:07:57 +08:00
|
|
|
res = error(_("failed to write commit object"));
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (update_head_with_reflog(current_head, oid,
|
|
|
|
|
getenv("GIT_REFLOG_ACTION"), msg, &err)) {
|
|
|
|
|
res = error("%s", err.buf);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (flags & AMEND_MSG)
|
2019-01-12 10:13:23 +08:00
|
|
|
commit_post_rewrite(r, current_head, oid);
|
2017-11-24 19:07:57 +08:00
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
free_commit_extra_headers(extra);
|
|
|
|
|
strbuf_release(&err);
|
2018-01-24 20:34:22 +08:00
|
|
|
strbuf_release(&commit_msg);
|
2017-11-24 19:07:57 +08:00
|
|
|
free(amend_author);
|
|
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_commit(struct repository *r,
|
|
|
|
|
const char *msg_file, const char *author,
|
2017-11-24 19:07:57 +08:00
|
|
|
struct replay_opts *opts, unsigned int flags)
|
|
|
|
|
{
|
|
|
|
|
int res = 1;
|
|
|
|
|
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
if (!(flags & EDIT_MSG) && !(flags & VERIFY_MSG) &&
|
|
|
|
|
!(flags & CREATE_ROOT_COMMIT)) {
|
2017-11-24 19:07:57 +08:00
|
|
|
struct object_id oid;
|
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
if (msg_file && strbuf_read_file(&sb, msg_file, 2048) < 0)
|
|
|
|
|
return error_errno(_("unable to read commit message "
|
|
|
|
|
"from '%s'"),
|
|
|
|
|
msg_file);
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
res = try_to_commit(r, msg_file ? &sb : NULL,
|
|
|
|
|
author, opts, flags, &oid);
|
2017-11-24 19:07:57 +08:00
|
|
|
strbuf_release(&sb);
|
|
|
|
|
if (!res) {
|
2018-11-10 13:48:56 +08:00
|
|
|
unlink(git_path_cherry_pick_head(r));
|
|
|
|
|
unlink(git_path_merge_msg(r));
|
2017-11-24 19:07:57 +08:00
|
|
|
if (!is_rebase_i(opts))
|
2018-11-10 13:48:56 +08:00
|
|
|
print_commit_summary(r, NULL, &oid,
|
2017-11-24 19:07:57 +08:00
|
|
|
SUMMARY_SHOW_AUTHOR_DATE);
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (res == 1)
|
2018-11-10 13:48:56 +08:00
|
|
|
return run_git_commit(r, msg_file, opts, flags);
|
2017-11-24 19:07:57 +08:00
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
static int is_original_commit_empty(struct commit *commit)
|
|
|
|
|
{
|
2017-07-14 07:49:22 +08:00
|
|
|
const struct object_id *ptree_oid;
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
|
|
|
|
|
if (parse_commit(commit))
|
2017-12-23 07:55:43 +08:00
|
|
|
return error(_("could not parse commit %s"),
|
2015-11-10 10:22:28 +08:00
|
|
|
oid_to_hex(&commit->object.oid));
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
if (commit->parents) {
|
|
|
|
|
struct commit *parent = commit->parents->item;
|
|
|
|
|
if (parse_commit(parent))
|
2017-12-23 07:55:43 +08:00
|
|
|
return error(_("could not parse parent commit %s"),
|
2015-11-10 10:22:28 +08:00
|
|
|
oid_to_hex(&parent->object.oid));
|
2018-04-07 03:09:38 +08:00
|
|
|
ptree_oid = get_commit_tree_oid(parent);
|
git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-20 22:36:15 +08:00
|
|
|
} else {
|
2017-11-13 05:28:54 +08:00
|
|
|
ptree_oid = the_hash_algo->empty_tree; /* commit is root */
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
return oideq(ptree_oid, get_commit_tree_oid(commit));
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2012-05-30 08:14:41 +08:00
|
|
|
/*
|
|
|
|
|
* Do we run "git commit" with "--allow-empty"?
|
|
|
|
|
*/
|
2018-11-10 13:48:56 +08:00
|
|
|
static int allow_empty(struct repository *r,
|
|
|
|
|
struct replay_opts *opts,
|
|
|
|
|
struct commit *commit)
|
2012-05-30 08:14:41 +08:00
|
|
|
{
|
|
|
|
|
int index_unchanged, empty_commit;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Three cases:
|
|
|
|
|
*
|
|
|
|
|
* (1) we do not allow empty at all and error out.
|
|
|
|
|
*
|
|
|
|
|
* (2) we allow ones that were initially empty, but
|
|
|
|
|
* forbid the ones that become empty;
|
|
|
|
|
*
|
|
|
|
|
* (3) we allow both.
|
|
|
|
|
*/
|
|
|
|
|
if (!opts->allow_empty)
|
|
|
|
|
return 0; /* let "git commit" barf as necessary */
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
index_unchanged = is_index_unchanged(r);
|
2012-05-30 08:14:41 +08:00
|
|
|
if (index_unchanged < 0)
|
|
|
|
|
return index_unchanged;
|
|
|
|
|
if (!index_unchanged)
|
|
|
|
|
return 0; /* we do not have to say --allow-empty */
|
|
|
|
|
|
|
|
|
|
if (opts->keep_redundant_commits)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
empty_commit = is_original_commit_empty(commit);
|
|
|
|
|
if (empty_commit < 0)
|
|
|
|
|
return empty_commit;
|
|
|
|
|
if (!empty_commit)
|
|
|
|
|
return 0;
|
|
|
|
|
else
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:27:15 +08:00
|
|
|
static struct {
|
|
|
|
|
char c;
|
|
|
|
|
const char *str;
|
|
|
|
|
} todo_command_info[] = {
|
|
|
|
|
{ 'p', "pick" },
|
|
|
|
|
{ 0, "revert" },
|
|
|
|
|
{ 'e', "edit" },
|
2017-01-02 23:28:00 +08:00
|
|
|
{ 'r', "reword" },
|
2017-01-02 23:27:15 +08:00
|
|
|
{ 'f', "fixup" },
|
|
|
|
|
{ 's', "squash" },
|
|
|
|
|
{ 'x', "exec" },
|
2018-10-12 21:14:26 +08:00
|
|
|
{ 'b', "break" },
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
{ 'l', "label" },
|
|
|
|
|
{ 't', "reset" },
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
{ 'm', "merge" },
|
2017-01-02 23:34:34 +08:00
|
|
|
{ 0, "noop" },
|
2017-01-02 23:34:39 +08:00
|
|
|
{ 'd', "drop" },
|
|
|
|
|
{ 0, NULL }
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const char *command_to_string(const enum todo_command command)
|
|
|
|
|
{
|
2017-01-02 23:34:39 +08:00
|
|
|
if (command < TODO_COMMENT)
|
2017-01-02 23:27:15 +08:00
|
|
|
return todo_command_info[command].str;
|
2018-07-21 15:49:38 +08:00
|
|
|
die(_("unknown command: %d"), command);
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
}
|
|
|
|
|
|
2017-12-28 03:12:45 +08:00
|
|
|
static char command_to_char(const enum todo_command command)
|
2017-12-06 01:52:34 +08:00
|
|
|
{
|
|
|
|
|
if (command < TODO_COMMENT && todo_command_info[command].c)
|
|
|
|
|
return todo_command_info[command].c;
|
|
|
|
|
return comment_line_char;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:26:38 +08:00
|
|
|
static int is_noop(const enum todo_command command)
|
|
|
|
|
{
|
2017-01-02 23:34:34 +08:00
|
|
|
return TODO_NOOP <= command;
|
2017-01-02 23:26:38 +08:00
|
|
|
}
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
static int is_fixup(enum todo_command command)
|
|
|
|
|
{
|
|
|
|
|
return command == TODO_FIXUP || command == TODO_SQUASH;
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
/* Does this command create a (non-merge) commit? */
|
|
|
|
|
static int is_pick_or_similar(enum todo_command command)
|
|
|
|
|
{
|
|
|
|
|
switch (command) {
|
|
|
|
|
case TODO_PICK:
|
|
|
|
|
case TODO_REVERT:
|
|
|
|
|
case TODO_EDIT:
|
|
|
|
|
case TODO_REWORD:
|
|
|
|
|
case TODO_FIXUP:
|
|
|
|
|
case TODO_SQUASH:
|
|
|
|
|
return 1;
|
|
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int update_squash_messages(struct repository *r,
|
|
|
|
|
enum todo_command command,
|
|
|
|
|
struct commit *commit,
|
|
|
|
|
struct replay_opts *opts)
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
{
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2018-04-28 04:48:21 +08:00
|
|
|
int res;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
const char *message, *body;
|
|
|
|
|
|
2018-04-28 04:48:21 +08:00
|
|
|
if (opts->current_fixup_count > 0) {
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
struct strbuf header = STRBUF_INIT;
|
2018-04-28 04:48:21 +08:00
|
|
|
char *eol;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
|
2018-04-28 04:48:21 +08:00
|
|
|
if (strbuf_read_file(&buf, rebase_path_squash_msg(), 9) <= 0)
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
return error(_("could not read '%s'"),
|
|
|
|
|
rebase_path_squash_msg());
|
|
|
|
|
|
2018-04-28 04:48:21 +08:00
|
|
|
eol = buf.buf[0] != comment_line_char ?
|
|
|
|
|
buf.buf : strchrnul(buf.buf, '\n');
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
|
|
|
|
|
strbuf_addf(&header, "%c ", comment_line_char);
|
2018-04-28 04:48:21 +08:00
|
|
|
strbuf_addf(&header, _("This is a combination of %d commits."),
|
|
|
|
|
opts->current_fixup_count + 2);
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
strbuf_splice(&buf, 0, eol - buf.buf, header.buf, header.len);
|
|
|
|
|
strbuf_release(&header);
|
|
|
|
|
} else {
|
2017-05-07 06:10:07 +08:00
|
|
|
struct object_id head;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
struct commit *head_commit;
|
|
|
|
|
const char *head_message, *body;
|
|
|
|
|
|
2017-05-07 06:10:07 +08:00
|
|
|
if (get_oid("HEAD", &head))
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
return error(_("need a HEAD to fixup"));
|
2018-11-10 13:48:57 +08:00
|
|
|
if (!(head_commit = lookup_commit_reference(r, &head)))
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
return error(_("could not read HEAD"));
|
|
|
|
|
if (!(head_message = get_commit_buffer(head_commit, NULL)))
|
|
|
|
|
return error(_("could not read HEAD's commit message"));
|
|
|
|
|
|
|
|
|
|
find_commit_subject(head_message, &body);
|
|
|
|
|
if (write_message(body, strlen(body),
|
|
|
|
|
rebase_path_fixup_msg(), 0)) {
|
|
|
|
|
unuse_commit_buffer(head_commit, head_message);
|
|
|
|
|
return error(_("cannot write '%s'"),
|
|
|
|
|
rebase_path_fixup_msg());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
strbuf_addf(&buf, "%c ", comment_line_char);
|
2018-04-28 04:48:21 +08:00
|
|
|
strbuf_addf(&buf, _("This is a combination of %d commits."), 2);
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
strbuf_addf(&buf, "\n%c ", comment_line_char);
|
|
|
|
|
strbuf_addstr(&buf, _("This is the 1st commit message:"));
|
|
|
|
|
strbuf_addstr(&buf, "\n\n");
|
|
|
|
|
strbuf_addstr(&buf, body);
|
|
|
|
|
|
|
|
|
|
unuse_commit_buffer(head_commit, head_message);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!(message = get_commit_buffer(commit, NULL)))
|
|
|
|
|
return error(_("could not read commit message of %s"),
|
|
|
|
|
oid_to_hex(&commit->object.oid));
|
|
|
|
|
find_commit_subject(message, &body);
|
|
|
|
|
|
|
|
|
|
if (command == TODO_SQUASH) {
|
|
|
|
|
unlink(rebase_path_fixup_msg());
|
|
|
|
|
strbuf_addf(&buf, "\n%c ", comment_line_char);
|
2018-04-28 04:48:21 +08:00
|
|
|
strbuf_addf(&buf, _("This is the commit message #%d:"),
|
2018-08-15 17:41:25 +08:00
|
|
|
++opts->current_fixup_count + 1);
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
strbuf_addstr(&buf, "\n\n");
|
|
|
|
|
strbuf_addstr(&buf, body);
|
|
|
|
|
} else if (command == TODO_FIXUP) {
|
|
|
|
|
strbuf_addf(&buf, "\n%c ", comment_line_char);
|
|
|
|
|
strbuf_addf(&buf, _("The commit message #%d will be skipped:"),
|
2018-08-15 17:41:25 +08:00
|
|
|
++opts->current_fixup_count + 1);
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
strbuf_addstr(&buf, "\n\n");
|
|
|
|
|
strbuf_add_commented_lines(&buf, body, strlen(body));
|
|
|
|
|
} else
|
|
|
|
|
return error(_("unknown command: %d"), command);
|
|
|
|
|
unuse_commit_buffer(commit, message);
|
|
|
|
|
|
|
|
|
|
res = write_message(buf.buf, buf.len, rebase_path_squash_msg(), 0);
|
|
|
|
|
strbuf_release(&buf);
|
2018-04-28 04:48:21 +08:00
|
|
|
|
|
|
|
|
if (!res) {
|
|
|
|
|
strbuf_addf(&opts->current_fixups, "%s%s %s",
|
|
|
|
|
opts->current_fixups.len ? "\n" : "",
|
|
|
|
|
command_to_string(command),
|
|
|
|
|
oid_to_hex(&commit->object.oid));
|
|
|
|
|
res = write_message(opts->current_fixups.buf,
|
|
|
|
|
opts->current_fixups.len,
|
|
|
|
|
rebase_path_current_fixups(), 0);
|
|
|
|
|
}
|
|
|
|
|
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-09 18:25:21 +08:00
|
|
|
static void flush_rewritten_pending(void)
|
|
|
|
|
{
|
2017-01-02 23:28:16 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2017-07-14 07:49:22 +08:00
|
|
|
struct object_id newoid;
|
2017-01-02 23:28:16 +08:00
|
|
|
FILE *out;
|
|
|
|
|
|
2017-07-14 07:49:22 +08:00
|
|
|
if (strbuf_read_file(&buf, rebase_path_rewritten_pending(), (GIT_MAX_HEXSZ + 1) * 2) > 0 &&
|
|
|
|
|
!get_oid("HEAD", &newoid) &&
|
2017-05-03 18:16:50 +08:00
|
|
|
(out = fopen_or_warn(rebase_path_rewritten_list(), "a"))) {
|
2017-01-02 23:28:16 +08:00
|
|
|
char *bol = buf.buf, *eol;
|
|
|
|
|
|
|
|
|
|
while (*bol) {
|
|
|
|
|
eol = strchrnul(bol, '\n');
|
|
|
|
|
fprintf(out, "%.*s %s\n", (int)(eol - bol),
|
2017-07-14 07:49:22 +08:00
|
|
|
bol, oid_to_hex(&newoid));
|
2017-01-02 23:28:16 +08:00
|
|
|
if (!*eol)
|
|
|
|
|
break;
|
|
|
|
|
bol = eol + 1;
|
|
|
|
|
}
|
|
|
|
|
fclose(out);
|
|
|
|
|
unlink(rebase_path_rewritten_pending());
|
|
|
|
|
}
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void record_in_rewritten(struct object_id *oid,
|
2018-12-09 18:25:21 +08:00
|
|
|
enum todo_command next_command)
|
|
|
|
|
{
|
2017-05-03 18:16:50 +08:00
|
|
|
FILE *out = fopen_or_warn(rebase_path_rewritten_pending(), "a");
|
2017-01-02 23:28:16 +08:00
|
|
|
|
|
|
|
|
if (!out)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
fprintf(out, "%s\n", oid_to_hex(oid));
|
|
|
|
|
fclose(out);
|
|
|
|
|
|
|
|
|
|
if (!is_fixup(next_command))
|
|
|
|
|
flush_rewritten_pending();
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_pick_commit(struct repository *r,
|
|
|
|
|
enum todo_command command,
|
|
|
|
|
struct commit *commit,
|
|
|
|
|
struct replay_opts *opts,
|
|
|
|
|
int final_fixup)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2017-03-24 00:07:11 +08:00
|
|
|
unsigned int flags = opts->edit ? EDIT_MSG : 0;
|
2018-11-10 13:48:56 +08:00
|
|
|
const char *msg_file = opts->edit ? NULL : git_path_merge_msg(r);
|
2017-05-07 06:10:32 +08:00
|
|
|
struct object_id head;
|
2012-01-12 02:15:57 +08:00
|
|
|
struct commit *base, *next, *parent;
|
|
|
|
|
const char *base_label, *next_label;
|
2017-11-24 19:07:57 +08:00
|
|
|
char *author = NULL;
|
2014-06-11 05:39:35 +08:00
|
|
|
struct commit_message msg = { NULL, NULL, NULL, NULL };
|
2012-01-12 02:15:57 +08:00
|
|
|
struct strbuf msgbuf = STRBUF_INIT;
|
2017-03-24 00:07:11 +08:00
|
|
|
int res, unborn = 0, allow;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
if (opts->no_commit) {
|
|
|
|
|
/*
|
|
|
|
|
* We do not intend to commit immediately. We just want to
|
|
|
|
|
* merge the differences in, so let's compute the tree
|
|
|
|
|
* that represents the "current" state for merge-recursive
|
|
|
|
|
* to work on.
|
|
|
|
|
*/
|
2018-11-10 13:48:56 +08:00
|
|
|
if (write_index_as_tree(&head, r->index, r->index_file, 0, NULL))
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("your index file is unmerged."));
|
2012-01-12 02:15:57 +08:00
|
|
|
} else {
|
2017-05-07 06:10:32 +08:00
|
|
|
unborn = get_oid("HEAD", &head);
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
/* Do we want to generate a root commit? */
|
|
|
|
|
if (is_pick_or_similar(command) && opts->have_squash_onto &&
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
oideq(&head, &opts->squash_onto)) {
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
if (is_fixup(command))
|
|
|
|
|
return error(_("cannot fixup root commit"));
|
|
|
|
|
flags |= CREATE_ROOT_COMMIT;
|
|
|
|
|
unborn = 1;
|
|
|
|
|
} else if (unborn)
|
2017-11-13 05:28:54 +08:00
|
|
|
oidcpy(&head, the_hash_algo->empty_tree);
|
2018-11-10 13:49:04 +08:00
|
|
|
if (index_differs_from(r, unborn ? empty_tree_oid_hex() : "HEAD",
|
2017-11-01 02:19:05 +08:00
|
|
|
NULL, 0))
|
2019-01-12 10:13:26 +08:00
|
|
|
return error_dirty_index(r, opts);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
2018-11-10 13:48:56 +08:00
|
|
|
discard_index(r->index);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2017-01-02 23:26:08 +08:00
|
|
|
if (!commit->parents)
|
2012-01-12 02:15:57 +08:00
|
|
|
parent = NULL;
|
|
|
|
|
else if (commit->parents->next) {
|
|
|
|
|
/* Reverting or cherry-picking a merge commit */
|
|
|
|
|
int cnt;
|
|
|
|
|
struct commit_list *p;
|
|
|
|
|
|
|
|
|
|
if (!opts->mainline)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("commit %s is a merge but no -m option was given."),
|
2015-11-10 10:22:28 +08:00
|
|
|
oid_to_hex(&commit->object.oid));
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
for (cnt = 1, p = commit->parents;
|
|
|
|
|
cnt != opts->mainline && p;
|
|
|
|
|
cnt++)
|
|
|
|
|
p = p->next;
|
|
|
|
|
if (cnt != opts->mainline || !p)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("commit %s does not have parent %d"),
|
2015-11-10 10:22:28 +08:00
|
|
|
oid_to_hex(&commit->object.oid), opts->mainline);
|
2012-01-12 02:15:57 +08:00
|
|
|
parent = p->item;
|
2018-12-14 12:53:51 +08:00
|
|
|
} else if (1 < opts->mainline)
|
|
|
|
|
/*
|
|
|
|
|
* Non-first parent explicitly specified as mainline for
|
|
|
|
|
* non-merge commit
|
|
|
|
|
*/
|
|
|
|
|
return error(_("commit %s does not have parent %d"),
|
|
|
|
|
oid_to_hex(&commit->object.oid), opts->mainline);
|
2012-01-12 02:15:57 +08:00
|
|
|
else
|
|
|
|
|
parent = commit->parents->item;
|
|
|
|
|
|
2017-01-02 23:28:05 +08:00
|
|
|
if (get_message(commit, &msg) != 0)
|
|
|
|
|
return error(_("cannot get commit message for %s"),
|
|
|
|
|
oid_to_hex(&commit->object.oid));
|
|
|
|
|
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
if (opts->allow_ff && !is_fixup(command) &&
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
((parent && oideq(&parent->object.oid, &head)) ||
|
2017-01-02 23:28:05 +08:00
|
|
|
(!parent && unborn))) {
|
|
|
|
|
if (is_rebase_i(opts))
|
|
|
|
|
write_author_script(msg.message);
|
2018-11-10 13:48:56 +08:00
|
|
|
res = fast_forward_to(r, &commit->object.oid, &head, unborn,
|
2017-01-02 23:28:05 +08:00
|
|
|
opts);
|
|
|
|
|
if (res || command != TODO_REWORD)
|
|
|
|
|
goto leave;
|
2017-12-23 07:55:53 +08:00
|
|
|
flags |= EDIT_MSG | AMEND_MSG | VERIFY_MSG;
|
2017-01-02 23:28:05 +08:00
|
|
|
msg_file = NULL;
|
|
|
|
|
goto fast_forward_edit;
|
|
|
|
|
}
|
2012-01-12 02:15:57 +08:00
|
|
|
if (parent && parse_commit(parent) < 0)
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
/* TRANSLATORS: The first %s will be a "todo" command like
|
|
|
|
|
"revert" or "pick", the second %s a SHA1. */
|
2012-01-12 02:15:57 +08:00
|
|
|
return error(_("%s: cannot parse parent commit %s"),
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
command_to_string(command),
|
|
|
|
|
oid_to_hex(&parent->object.oid));
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* "commit" is an existing commit. We would want to apply
|
|
|
|
|
* the difference it introduces since its first parent "prev"
|
|
|
|
|
* on top of the current HEAD if we are cherry-pick. Or the
|
|
|
|
|
* reverse of it if we are revert.
|
|
|
|
|
*/
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
if (command == TODO_REVERT) {
|
2012-01-12 02:15:57 +08:00
|
|
|
base = commit;
|
|
|
|
|
base_label = msg.label;
|
|
|
|
|
next = parent;
|
|
|
|
|
next_label = msg.parent_label;
|
|
|
|
|
strbuf_addstr(&msgbuf, "Revert \"");
|
|
|
|
|
strbuf_addstr(&msgbuf, msg.subject);
|
|
|
|
|
strbuf_addstr(&msgbuf, "\"\n\nThis reverts commit ");
|
2015-11-10 10:22:28 +08:00
|
|
|
strbuf_addstr(&msgbuf, oid_to_hex(&commit->object.oid));
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
if (commit->parents && commit->parents->next) {
|
|
|
|
|
strbuf_addstr(&msgbuf, ", reversing\nchanges made to ");
|
2015-11-10 10:22:28 +08:00
|
|
|
strbuf_addstr(&msgbuf, oid_to_hex(&parent->object.oid));
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
strbuf_addstr(&msgbuf, ".\n");
|
|
|
|
|
} else {
|
|
|
|
|
const char *p;
|
|
|
|
|
|
|
|
|
|
base = parent;
|
|
|
|
|
base_label = msg.parent_label;
|
|
|
|
|
next = commit;
|
|
|
|
|
next_label = msg.label;
|
|
|
|
|
|
2017-01-02 23:26:20 +08:00
|
|
|
/* Append the commit log message to msgbuf. */
|
|
|
|
|
if (find_commit_subject(msg.message, &p))
|
|
|
|
|
strbuf_addstr(&msgbuf, p);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
if (opts->record_origin) {
|
2017-04-27 04:50:03 +08:00
|
|
|
strbuf_complete_line(&msgbuf);
|
2013-02-12 18:17:35 +08:00
|
|
|
if (!has_conforming_footer(&msgbuf, NULL, 0))
|
2013-02-12 18:17:34 +08:00
|
|
|
strbuf_addch(&msgbuf, '\n');
|
2013-02-12 18:17:32 +08:00
|
|
|
strbuf_addstr(&msgbuf, cherry_picked_prefix);
|
2015-11-10 10:22:28 +08:00
|
|
|
strbuf_addstr(&msgbuf, oid_to_hex(&commit->object.oid));
|
2012-01-12 02:15:57 +08:00
|
|
|
strbuf_addstr(&msgbuf, ")\n");
|
|
|
|
|
}
|
2017-11-24 19:07:57 +08:00
|
|
|
if (!is_fixup(command))
|
|
|
|
|
author = get_author(msg.message);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:28:00 +08:00
|
|
|
if (command == TODO_REWORD)
|
2017-03-24 00:07:17 +08:00
|
|
|
flags |= EDIT_MSG | VERIFY_MSG;
|
2017-01-02 23:28:00 +08:00
|
|
|
else if (is_fixup(command)) {
|
2018-11-10 13:48:57 +08:00
|
|
|
if (update_squash_messages(r, command, commit, opts))
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
return -1;
|
2017-03-24 00:07:11 +08:00
|
|
|
flags |= AMEND_MSG;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
if (!final_fixup)
|
|
|
|
|
msg_file = rebase_path_squash_msg();
|
|
|
|
|
else if (file_exists(rebase_path_fixup_msg())) {
|
2017-03-24 00:07:11 +08:00
|
|
|
flags |= CLEANUP_MSG;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
msg_file = rebase_path_fixup_msg();
|
|
|
|
|
} else {
|
2018-11-10 13:48:56 +08:00
|
|
|
const char *dest = git_path_squash_msg(r);
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
unlink(dest);
|
|
|
|
|
if (copy_file(dest, rebase_path_squash_msg(), 0666))
|
|
|
|
|
return error(_("could not rename '%s' to '%s'"),
|
|
|
|
|
rebase_path_squash_msg(), dest);
|
2018-11-10 13:48:56 +08:00
|
|
|
unlink(git_path_merge_msg(r));
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
msg_file = dest;
|
2017-03-24 00:07:11 +08:00
|
|
|
flags |= EDIT_MSG;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-20 19:10:55 +08:00
|
|
|
if (opts->signoff && !is_fixup(command))
|
2017-11-24 19:07:55 +08:00
|
|
|
append_signoff(&msgbuf, 0, 0);
|
|
|
|
|
|
2017-01-02 23:27:18 +08:00
|
|
|
if (is_rebase_i(opts) && write_author_script(msg.message) < 0)
|
|
|
|
|
res = -1;
|
|
|
|
|
else if (!opts->strategy || !strcmp(opts->strategy, "recursive") || command == TODO_REVERT) {
|
2018-11-10 13:48:56 +08:00
|
|
|
res = do_recursive_merge(r, base, next, base_label, next_label,
|
2017-05-07 06:10:36 +08:00
|
|
|
&head, &msgbuf, opts);
|
prepare the builtins for a libified merge_recursive()
Previously, callers of merge_trees() or merge_recursive() expected that
code to die() with an error message. This used to be okay because we
called those commands from scripts, and had a chance to print out a
message in case the command failed fatally (read: with exit code 128).
As scripting incurs its own set of problems (portability, speed,
idiosyncrasies of different shells, limited data structures leading to
inefficient code), we are converting more and more of these scripts into
builtins, using library functions directly.
We already tried to use merge_recursive() directly in the builtin
git-am, for example. Unfortunately, we had to roll it back temporarily
because some of the code in merge-recursive.c still deemed it okay to
call die(), when the builtin am code really wanted to print out a useful
advice after the merge failed fatally. In the next commits, we want to
fix that.
The code touched by this commit expected merge_trees() to die() with
some useful message when there is an error condition, but merge_trees()
is going to be improved by converting all die() calls to return error()
instead (i.e. return value -1 after printing out the message as before),
so that the caller can react more flexibly.
This is a step to prepare for the version of merge_trees() that no
longer dies, even if we just imitate the previous behavior by calling
exit(128): this is what callers of e.g. `git merge` have come to expect.
Note that the callers of the sequencer (revert and cherry-pick) already
fail fast even for the return value -1; The only difference is that they
now get a chance to say "<command> failed".
A caller of merge_trees() might want handle error messages themselves
(or even suppress them). As this patch is already complex enough, we
leave that change for a later patch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27 00:06:02 +08:00
|
|
|
if (res < 0)
|
2018-06-02 04:01:45 +08:00
|
|
|
goto leave;
|
|
|
|
|
|
2016-10-21 20:26:05 +08:00
|
|
|
res |= write_message(msgbuf.buf, msgbuf.len,
|
2018-11-10 13:48:56 +08:00
|
|
|
git_path_merge_msg(r), 0);
|
2012-01-12 02:15:57 +08:00
|
|
|
} else {
|
|
|
|
|
struct commit_list *common = NULL;
|
|
|
|
|
struct commit_list *remotes = NULL;
|
|
|
|
|
|
2016-10-21 20:26:05 +08:00
|
|
|
res = write_message(msgbuf.buf, msgbuf.len,
|
2018-11-10 13:48:56 +08:00
|
|
|
git_path_merge_msg(r), 0);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
commit_list_insert(base, &common);
|
|
|
|
|
commit_list_insert(next, &remotes);
|
2018-11-10 13:48:56 +08:00
|
|
|
res |= try_merge_command(r, opts->strategy,
|
2016-10-21 20:24:13 +08:00
|
|
|
opts->xopts_nr, (const char **)opts->xopts,
|
2017-05-07 06:10:32 +08:00
|
|
|
common, oid_to_hex(&head), remotes);
|
2012-01-12 02:15:57 +08:00
|
|
|
free_commit_list(common);
|
|
|
|
|
free_commit_list(remotes);
|
|
|
|
|
}
|
2016-10-21 20:25:41 +08:00
|
|
|
strbuf_release(&msgbuf);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the merge was clean or if it failed due to conflict, we write
|
|
|
|
|
* CHERRY_PICK_HEAD for the subsequent invocation of commit to use.
|
|
|
|
|
* However, if the merge did not even start, then we don't want to
|
|
|
|
|
* write it at all.
|
|
|
|
|
*/
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
if (command == TODO_PICK && !opts->no_commit && (res == 0 || res == 1) &&
|
2017-10-16 06:06:51 +08:00
|
|
|
update_ref(NULL, "CHERRY_PICK_HEAD", &commit->object.oid, NULL,
|
2017-11-05 16:42:06 +08:00
|
|
|
REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR))
|
2016-08-26 21:47:14 +08:00
|
|
|
res = -1;
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
if (command == TODO_REVERT && ((opts->no_commit && res == 0) || res == 1) &&
|
2017-10-16 06:06:51 +08:00
|
|
|
update_ref(NULL, "REVERT_HEAD", &commit->object.oid, NULL,
|
2017-11-05 16:42:06 +08:00
|
|
|
REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR))
|
2016-08-26 21:47:14 +08:00
|
|
|
res = -1;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
if (res) {
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
error(command == TODO_REVERT
|
2012-01-12 02:15:57 +08:00
|
|
|
? _("could not revert %s... %s")
|
|
|
|
|
: _("could not apply %s... %s"),
|
2016-10-21 20:24:37 +08:00
|
|
|
short_commit_name(commit), msg.subject);
|
2018-11-10 13:48:57 +08:00
|
|
|
print_advice(r, res == 1, opts);
|
2018-11-10 13:48:56 +08:00
|
|
|
repo_rerere(r, opts->allow_rerere_auto);
|
2013-05-29 11:56:21 +08:00
|
|
|
goto leave;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
allow = allow_empty(r, opts, commit);
|
2013-06-06 16:58:57 +08:00
|
|
|
if (allow < 0) {
|
|
|
|
|
res = allow;
|
|
|
|
|
goto leave;
|
2017-03-24 00:07:11 +08:00
|
|
|
} else if (allow)
|
|
|
|
|
flags |= ALLOW_EMPTY;
|
2017-11-24 19:07:57 +08:00
|
|
|
if (!opts->no_commit) {
|
2017-01-02 23:28:05 +08:00
|
|
|
fast_forward_edit:
|
2017-11-24 19:07:57 +08:00
|
|
|
if (author || command == TODO_REVERT || (flags & AMEND_MSG))
|
2018-11-10 13:48:56 +08:00
|
|
|
res = do_commit(r, msg_file, author, opts, flags);
|
2017-11-24 19:07:57 +08:00
|
|
|
else
|
|
|
|
|
res = error(_("unable to parse commit author"));
|
|
|
|
|
}
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
|
|
|
|
|
if (!res && final_fixup) {
|
|
|
|
|
unlink(rebase_path_fixup_msg());
|
|
|
|
|
unlink(rebase_path_squash_msg());
|
2018-04-28 04:48:21 +08:00
|
|
|
unlink(rebase_path_current_fixups());
|
|
|
|
|
strbuf_reset(&opts->current_fixups);
|
|
|
|
|
opts->current_fixup_count = 0;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
}
|
2013-05-29 11:56:21 +08:00
|
|
|
|
|
|
|
|
leave:
|
2014-06-11 05:39:35 +08:00
|
|
|
free_message(commit, &msg);
|
2017-11-24 19:07:57 +08:00
|
|
|
free(author);
|
2016-12-08 05:51:32 +08:00
|
|
|
update_abort_safety_file();
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-09 22:37:18 +08:00
|
|
|
static int prepare_revs(struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2012-08-29 14:15:56 +08:00
|
|
|
/*
|
|
|
|
|
* picking (but not reverting) ranges (but not individual revisions)
|
|
|
|
|
* should be done in reverse
|
|
|
|
|
*/
|
|
|
|
|
if (opts->action == REPLAY_PICK && !opts->revs->no_walk)
|
2012-01-12 02:15:57 +08:00
|
|
|
opts->revs->reverse ^= 1;
|
|
|
|
|
|
|
|
|
|
if (prepare_revision_walk(opts->revs))
|
2016-09-09 22:37:18 +08:00
|
|
|
return error(_("revision walk setup failed"));
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2016-09-09 22:37:18 +08:00
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int read_and_refresh_cache(struct repository *r,
|
|
|
|
|
struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2018-02-28 05:30:09 +08:00
|
|
|
struct lock_file index_lock = LOCK_INIT;
|
2019-01-12 10:13:24 +08:00
|
|
|
int index_fd = repo_hold_locked_index(r, &index_lock, 0);
|
|
|
|
|
if (repo_read_index(r) < 0) {
|
2016-09-09 22:38:20 +08:00
|
|
|
rollback_lock_file(&index_lock);
|
2016-09-09 22:37:21 +08:00
|
|
|
return error(_("git %s: failed to read the index"),
|
2016-10-21 20:26:17 +08:00
|
|
|
_(action_name(opts)));
|
2016-09-09 22:38:20 +08:00
|
|
|
}
|
2018-11-10 13:48:56 +08:00
|
|
|
refresh_index(r->index, REFRESH_QUIET|REFRESH_UNMERGED, NULL, NULL, NULL);
|
2018-03-02 04:40:20 +08:00
|
|
|
if (index_fd >= 0) {
|
2018-11-10 13:48:56 +08:00
|
|
|
if (write_locked_index(r->index, &index_lock,
|
2018-03-02 04:40:20 +08:00
|
|
|
COMMIT_LOCK | SKIP_IF_UNCHANGED)) {
|
2016-09-09 22:37:21 +08:00
|
|
|
return error(_("git %s: failed to refresh the index"),
|
2016-10-21 20:26:17 +08:00
|
|
|
_(action_name(opts)));
|
2016-09-09 22:38:20 +08:00
|
|
|
}
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
2016-09-09 22:37:21 +08:00
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
enum todo_item_flags {
|
|
|
|
|
TODO_EDIT_MERGE_MSG = 1
|
|
|
|
|
};
|
|
|
|
|
|
2018-12-30 00:03:59 +08:00
|
|
|
void todo_list_release(struct todo_list *todo_list)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
strbuf_release(&todo_list->buf);
|
2017-06-16 07:15:46 +08:00
|
|
|
FREE_AND_NULL(todo_list->items);
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
todo_list->nr = todo_list->alloc = 0;
|
|
|
|
|
}
|
2012-01-12 02:15:57 +08:00
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
static struct todo_item *append_new_todo(struct todo_list *todo_list)
|
|
|
|
|
{
|
|
|
|
|
ALLOC_GROW(todo_list->items, todo_list->nr + 1, todo_list->alloc);
|
|
|
|
|
return todo_list->items + todo_list->nr++;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2019-01-29 23:01:46 +08:00
|
|
|
const char *todo_item_get_arg(struct todo_list *todo_list,
|
|
|
|
|
struct todo_item *item)
|
|
|
|
|
{
|
|
|
|
|
return todo_list->buf.buf + item->arg_offset;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-27 22:12:45 +08:00
|
|
|
static int is_command(enum todo_command command, const char **bol)
|
|
|
|
|
{
|
|
|
|
|
const char *str = todo_command_info[command].str;
|
|
|
|
|
const char nick = todo_command_info[command].c;
|
|
|
|
|
const char *p = *bol + 1;
|
|
|
|
|
|
|
|
|
|
return skip_prefix(*bol, str, bol) ||
|
|
|
|
|
((nick && **bol == nick) &&
|
|
|
|
|
(*p == ' ' || *p == '\t' || *p == '\n' || *p == '\r' || !*p) &&
|
|
|
|
|
(*bol = p));
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int parse_insn_line(struct repository *r, struct todo_item *item,
|
2019-01-29 23:01:46 +08:00
|
|
|
const char *buf, const char *bol, char *eol)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2017-05-07 06:10:09 +08:00
|
|
|
struct object_id commit_oid;
|
2012-01-12 02:15:57 +08:00
|
|
|
char *end_of_object_name;
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
int i, saved, status, padding;
|
|
|
|
|
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
item->flags = 0;
|
|
|
|
|
|
2016-10-21 20:25:36 +08:00
|
|
|
/* left-trim */
|
|
|
|
|
bol += strspn(bol, " \t");
|
|
|
|
|
|
2017-01-02 23:26:38 +08:00
|
|
|
if (bol == eol || *bol == '\r' || *bol == comment_line_char) {
|
2017-01-02 23:34:39 +08:00
|
|
|
item->command = TODO_COMMENT;
|
2017-01-02 23:26:38 +08:00
|
|
|
item->commit = NULL;
|
2019-01-29 23:01:46 +08:00
|
|
|
item->arg_offset = bol - buf;
|
2017-01-02 23:26:38 +08:00
|
|
|
item->arg_len = eol - bol;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:34:39 +08:00
|
|
|
for (i = 0; i < TODO_COMMENT; i++)
|
2019-06-27 22:12:45 +08:00
|
|
|
if (is_command(i, &bol)) {
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
item->command = i;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2017-01-02 23:34:39 +08:00
|
|
|
if (i >= TODO_COMMENT)
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
return -1;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2017-12-23 07:55:57 +08:00
|
|
|
/* Eat up extra spaces/ tabs before object name */
|
|
|
|
|
padding = strspn(bol, " \t");
|
|
|
|
|
bol += padding;
|
|
|
|
|
|
2018-10-12 21:14:26 +08:00
|
|
|
if (item->command == TODO_NOOP || item->command == TODO_BREAK) {
|
2017-12-23 07:55:57 +08:00
|
|
|
if (bol != eol)
|
|
|
|
|
return error(_("%s does not accept arguments: '%s'"),
|
|
|
|
|
command_to_string(item->command), bol);
|
2017-01-02 23:26:38 +08:00
|
|
|
item->commit = NULL;
|
2019-01-29 23:01:46 +08:00
|
|
|
item->arg_offset = bol - buf;
|
2017-01-02 23:26:38 +08:00
|
|
|
item->arg_len = eol - bol;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
if (!padding)
|
2017-12-23 07:55:57 +08:00
|
|
|
return error(_("missing arguments for %s"),
|
|
|
|
|
command_to_string(item->command));
|
2012-01-12 02:15:57 +08:00
|
|
|
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
if (item->command == TODO_EXEC || item->command == TODO_LABEL ||
|
|
|
|
|
item->command == TODO_RESET) {
|
2017-12-04 06:17:15 +08:00
|
|
|
item->commit = NULL;
|
2019-01-29 23:01:46 +08:00
|
|
|
item->arg_offset = bol - buf;
|
2017-01-02 23:26:47 +08:00
|
|
|
item->arg_len = (int)(eol - bol);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
if (item->command == TODO_MERGE) {
|
|
|
|
|
if (skip_prefix(bol, "-C", &bol))
|
|
|
|
|
bol += strspn(bol, " \t");
|
|
|
|
|
else if (skip_prefix(bol, "-c", &bol)) {
|
|
|
|
|
bol += strspn(bol, " \t");
|
|
|
|
|
item->flags |= TODO_EDIT_MERGE_MSG;
|
|
|
|
|
} else {
|
|
|
|
|
item->flags |= TODO_EDIT_MERGE_MSG;
|
|
|
|
|
item->commit = NULL;
|
2019-01-29 23:01:46 +08:00
|
|
|
item->arg_offset = bol - buf;
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
item->arg_len = (int)(eol - bol);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
end_of_object_name = (char *) bol + strcspn(bol, " \t\n");
|
2012-01-12 02:15:57 +08:00
|
|
|
saved = *end_of_object_name;
|
|
|
|
|
*end_of_object_name = '\0';
|
2017-05-07 06:10:09 +08:00
|
|
|
status = get_oid(bol, &commit_oid);
|
2012-01-12 02:15:57 +08:00
|
|
|
*end_of_object_name = saved;
|
|
|
|
|
|
2019-01-29 23:01:46 +08:00
|
|
|
bol = end_of_object_name + strspn(end_of_object_name, " \t");
|
|
|
|
|
item->arg_offset = bol - buf;
|
|
|
|
|
item->arg_len = (int)(eol - bol);
|
2016-10-21 20:25:00 +08:00
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
if (status < 0)
|
2019-03-13 18:16:32 +08:00
|
|
|
return error(_("could not parse '%.*s'"),
|
|
|
|
|
(int)(end_of_object_name - bol), bol);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
item->commit = lookup_commit_reference(r, &commit_oid);
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
return !item->commit;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2019-04-16 18:18:42 +08:00
|
|
|
int sequencer_get_last_command(struct repository *r, enum replay_action *action)
|
|
|
|
|
{
|
2019-06-27 22:12:46 +08:00
|
|
|
const char *todo_file, *bol;
|
2019-04-16 18:18:42 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2019-06-27 22:12:46 +08:00
|
|
|
int ret = 0;
|
2019-04-16 18:18:42 +08:00
|
|
|
|
|
|
|
|
todo_file = git_path_todo_file();
|
|
|
|
|
if (strbuf_read_file(&buf, todo_file, 0) < 0) {
|
2019-06-27 22:12:46 +08:00
|
|
|
if (errno == ENOENT || errno == ENOTDIR)
|
2019-04-16 18:18:42 +08:00
|
|
|
return -1;
|
|
|
|
|
else
|
|
|
|
|
return error_errno("unable to open '%s'", todo_file);
|
|
|
|
|
}
|
2019-06-27 22:12:46 +08:00
|
|
|
bol = buf.buf + strspn(buf.buf, " \t\r\n");
|
|
|
|
|
if (is_command(TODO_PICK, &bol) && (*bol == ' ' || *bol == '\t'))
|
2019-04-16 18:18:42 +08:00
|
|
|
*action = REPLAY_PICK;
|
2019-06-27 22:12:46 +08:00
|
|
|
else if (is_command(TODO_REVERT, &bol) &&
|
|
|
|
|
(*bol == ' ' || *bol == '\t'))
|
2019-04-16 18:18:42 +08:00
|
|
|
*action = REPLAY_REVERT;
|
|
|
|
|
else
|
2019-06-27 22:12:46 +08:00
|
|
|
ret = -1;
|
2019-04-16 18:18:42 +08:00
|
|
|
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-30 00:03:59 +08:00
|
|
|
int todo_list_parse_insn_buffer(struct repository *r, char *buf,
|
|
|
|
|
struct todo_list *todo_list)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
struct todo_item *item;
|
|
|
|
|
char *p = buf, *next_p;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
int i, res = 0, fixup_okay = file_exists(rebase_path_done());
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2018-12-30 00:03:58 +08:00
|
|
|
todo_list->current = todo_list->nr = 0;
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
for (i = 1; *p; i++, p = next_p) {
|
2012-01-12 02:15:57 +08:00
|
|
|
char *eol = strchrnul(p, '\n');
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
|
|
|
|
|
next_p = *eol ? eol + 1 /* skip LF */ : eol;
|
|
|
|
|
|
2016-10-21 20:24:46 +08:00
|
|
|
if (p != eol && eol[-1] == '\r')
|
|
|
|
|
eol--; /* strip Carriage Return */
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
item = append_new_todo(todo_list);
|
|
|
|
|
item->offset_in_buf = p - todo_list->buf.buf;
|
2019-01-29 23:01:46 +08:00
|
|
|
if (parse_insn_line(r, item, buf, p, eol)) {
|
2016-10-21 20:26:25 +08:00
|
|
|
res = error(_("invalid line %d: %.*s"),
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
i, (int)(eol - p), p);
|
2018-12-30 00:03:58 +08:00
|
|
|
item->command = TODO_COMMENT + 1;
|
2019-01-29 23:01:46 +08:00
|
|
|
item->arg_offset = p - buf;
|
2018-12-30 00:03:58 +08:00
|
|
|
item->arg_len = (int)(eol - p);
|
|
|
|
|
item->commit = NULL;
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
}
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
|
|
|
|
|
if (fixup_okay)
|
|
|
|
|
; /* do nothing */
|
|
|
|
|
else if (is_fixup(item->command))
|
|
|
|
|
return error(_("cannot '%s' without a previous commit"),
|
|
|
|
|
command_to_string(item->command));
|
|
|
|
|
else if (!is_noop(item->command))
|
|
|
|
|
fixup_okay = 1;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
2017-01-02 23:27:34 +08:00
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
return res;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:35:46 +08:00
|
|
|
static int count_commands(struct todo_list *todo_list)
|
|
|
|
|
{
|
|
|
|
|
int count = 0, i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < todo_list->nr; i++)
|
|
|
|
|
if (todo_list->items[i].command != TODO_COMMENT)
|
|
|
|
|
count++;
|
|
|
|
|
|
|
|
|
|
return count;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-25 20:28:29 +08:00
|
|
|
static int get_item_line_offset(struct todo_list *todo_list, int index)
|
|
|
|
|
{
|
|
|
|
|
return index < todo_list->nr ?
|
|
|
|
|
todo_list->items[index].offset_in_buf : todo_list->buf.len;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *get_item_line(struct todo_list *todo_list, int index)
|
|
|
|
|
{
|
|
|
|
|
return todo_list->buf.buf + get_item_line_offset(todo_list, index);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int get_item_line_length(struct todo_list *todo_list, int index)
|
|
|
|
|
{
|
|
|
|
|
return get_item_line_offset(todo_list, index + 1)
|
|
|
|
|
- get_item_line_offset(todo_list, index);
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-23 03:29:25 +08:00
|
|
|
static ssize_t strbuf_read_file_or_whine(struct strbuf *sb, const char *path)
|
|
|
|
|
{
|
|
|
|
|
int fd;
|
|
|
|
|
ssize_t len;
|
|
|
|
|
|
|
|
|
|
fd = open(path, O_RDONLY);
|
|
|
|
|
if (fd < 0)
|
|
|
|
|
return error_errno(_("could not open '%s'"), path);
|
|
|
|
|
len = strbuf_read(sb, fd, 0);
|
|
|
|
|
close(fd);
|
|
|
|
|
if (len < 0)
|
|
|
|
|
return error(_("could not read '%s'."), path);
|
|
|
|
|
return len;
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-16 18:18:41 +08:00
|
|
|
static int have_finished_the_last_pick(void)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
const char *eol;
|
|
|
|
|
const char *todo_path = git_path_todo_file();
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
if (strbuf_read_file(&buf, todo_path, 0) < 0) {
|
|
|
|
|
if (errno == ENOENT) {
|
|
|
|
|
return 0;
|
|
|
|
|
} else {
|
|
|
|
|
error_errno("unable to open '%s'", todo_path);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* If there is only one line then we are done */
|
|
|
|
|
eol = strchr(buf.buf, '\n');
|
|
|
|
|
if (!eol || !eol[1])
|
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-10 06:25:44 +08:00
|
|
|
void sequencer_post_commit_cleanup(struct repository *r, int verbose)
|
2019-04-16 18:18:41 +08:00
|
|
|
{
|
|
|
|
|
struct replay_opts opts = REPLAY_OPTS_INIT;
|
|
|
|
|
int need_cleanup = 0;
|
|
|
|
|
|
|
|
|
|
if (file_exists(git_path_cherry_pick_head(r))) {
|
2019-07-10 06:25:44 +08:00
|
|
|
if (!unlink(git_path_cherry_pick_head(r)) && verbose)
|
|
|
|
|
warning(_("cancelling a cherry picking in progress"));
|
2019-04-16 18:18:41 +08:00
|
|
|
opts.action = REPLAY_PICK;
|
|
|
|
|
need_cleanup = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (file_exists(git_path_revert_head(r))) {
|
2019-07-10 06:25:44 +08:00
|
|
|
if (!unlink(git_path_revert_head(r)) && verbose)
|
|
|
|
|
warning(_("cancelling a revert in progress"));
|
2019-04-16 18:18:41 +08:00
|
|
|
opts.action = REPLAY_REVERT;
|
|
|
|
|
need_cleanup = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!need_cleanup)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (!have_finished_the_last_pick())
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
sequencer_remove_state(&opts);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int read_populate_todo(struct repository *r,
|
|
|
|
|
struct todo_list *todo_list,
|
|
|
|
|
struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2017-04-27 03:17:40 +08:00
|
|
|
struct stat st;
|
2016-10-21 20:24:32 +08:00
|
|
|
const char *todo_file = get_todo_path(opts);
|
2018-02-23 03:29:25 +08:00
|
|
|
int res;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
strbuf_reset(&todo_list->buf);
|
2018-02-23 03:29:25 +08:00
|
|
|
if (strbuf_read_file_or_whine(&todo_list->buf, todo_file) < 0)
|
|
|
|
|
return -1;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2017-04-27 03:17:40 +08:00
|
|
|
res = stat(todo_file, &st);
|
|
|
|
|
if (res)
|
|
|
|
|
return error(_("could not stat '%s'"), todo_file);
|
|
|
|
|
fill_stat_data(&todo_list->stat, &st);
|
|
|
|
|
|
2018-12-30 00:03:59 +08:00
|
|
|
res = todo_list_parse_insn_buffer(r, todo_list->buf.buf, todo_list);
|
2017-01-02 23:35:42 +08:00
|
|
|
if (res) {
|
|
|
|
|
if (is_rebase_i(opts))
|
|
|
|
|
return error(_("please fix this using "
|
|
|
|
|
"'git rebase --edit-todo'."));
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("unusable instruction sheet: '%s'"), todo_file);
|
2017-01-02 23:35:42 +08:00
|
|
|
}
|
2016-10-21 20:26:13 +08:00
|
|
|
|
2017-01-02 23:27:34 +08:00
|
|
|
if (!todo_list->nr &&
|
|
|
|
|
(!is_rebase_i(opts) || !file_exists(rebase_path_done())))
|
|
|
|
|
return error(_("no commits parsed."));
|
|
|
|
|
|
2016-10-21 20:26:13 +08:00
|
|
|
if (!is_rebase_i(opts)) {
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
enum todo_command valid =
|
|
|
|
|
opts->action == REPLAY_PICK ? TODO_PICK : TODO_REVERT;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < todo_list->nr; i++)
|
|
|
|
|
if (valid == todo_list->items[i].command)
|
|
|
|
|
continue;
|
|
|
|
|
else if (valid == TODO_PICK)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("cannot cherry-pick during a revert."));
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
else
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("cannot revert during a cherry-pick."));
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:35:46 +08:00
|
|
|
if (is_rebase_i(opts)) {
|
|
|
|
|
struct todo_list done = TODO_LIST_INIT;
|
2017-05-03 18:16:50 +08:00
|
|
|
FILE *f = fopen_or_warn(rebase_path_msgtotal(), "w");
|
2017-01-02 23:35:46 +08:00
|
|
|
|
|
|
|
|
if (strbuf_read_file(&done.buf, rebase_path_done(), 0) > 0 &&
|
2018-12-30 00:03:59 +08:00
|
|
|
!todo_list_parse_insn_buffer(r, done.buf.buf, &done))
|
2017-01-02 23:35:46 +08:00
|
|
|
todo_list->done_nr = count_commands(&done);
|
|
|
|
|
else
|
|
|
|
|
todo_list->done_nr = 0;
|
|
|
|
|
|
|
|
|
|
todo_list->total_nr = todo_list->done_nr
|
|
|
|
|
+ count_commands(todo_list);
|
|
|
|
|
todo_list_release(&done);
|
2017-01-02 23:36:20 +08:00
|
|
|
|
|
|
|
|
if (f) {
|
|
|
|
|
fprintf(f, "%d\n", todo_list->total_nr);
|
|
|
|
|
fclose(f);
|
|
|
|
|
}
|
2017-01-02 23:35:46 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-09 22:37:24 +08:00
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:24:13 +08:00
|
|
|
static int git_config_string_dup(char **dest,
|
|
|
|
|
const char *var, const char *value)
|
|
|
|
|
{
|
|
|
|
|
if (!value)
|
|
|
|
|
return config_error_nonbool(var);
|
|
|
|
|
free(*dest);
|
|
|
|
|
*dest = xstrdup(value);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
static int populate_opts_cb(const char *key, const char *value, void *data)
|
|
|
|
|
{
|
|
|
|
|
struct replay_opts *opts = data;
|
|
|
|
|
int error_flag = 1;
|
|
|
|
|
|
|
|
|
|
if (!value)
|
|
|
|
|
error_flag = 0;
|
|
|
|
|
else if (!strcmp(key, "options.no-commit"))
|
|
|
|
|
opts->no_commit = git_config_bool_or_int(key, value, &error_flag);
|
|
|
|
|
else if (!strcmp(key, "options.edit"))
|
|
|
|
|
opts->edit = git_config_bool_or_int(key, value, &error_flag);
|
2019-03-14 02:26:15 +08:00
|
|
|
else if (!strcmp(key, "options.allow-empty"))
|
|
|
|
|
opts->allow_empty =
|
|
|
|
|
git_config_bool_or_int(key, value, &error_flag);
|
|
|
|
|
else if (!strcmp(key, "options.allow-empty-message"))
|
|
|
|
|
opts->allow_empty_message =
|
|
|
|
|
git_config_bool_or_int(key, value, &error_flag);
|
|
|
|
|
else if (!strcmp(key, "options.keep-redundant-commits"))
|
|
|
|
|
opts->keep_redundant_commits =
|
|
|
|
|
git_config_bool_or_int(key, value, &error_flag);
|
2012-01-12 02:15:57 +08:00
|
|
|
else if (!strcmp(key, "options.signoff"))
|
|
|
|
|
opts->signoff = git_config_bool_or_int(key, value, &error_flag);
|
|
|
|
|
else if (!strcmp(key, "options.record-origin"))
|
|
|
|
|
opts->record_origin = git_config_bool_or_int(key, value, &error_flag);
|
|
|
|
|
else if (!strcmp(key, "options.allow-ff"))
|
|
|
|
|
opts->allow_ff = git_config_bool_or_int(key, value, &error_flag);
|
|
|
|
|
else if (!strcmp(key, "options.mainline"))
|
|
|
|
|
opts->mainline = git_config_int(key, value);
|
|
|
|
|
else if (!strcmp(key, "options.strategy"))
|
2016-10-21 20:24:13 +08:00
|
|
|
git_config_string_dup(&opts->strategy, key, value);
|
2014-01-24 08:50:58 +08:00
|
|
|
else if (!strcmp(key, "options.gpg-sign"))
|
2016-10-21 20:24:13 +08:00
|
|
|
git_config_string_dup(&opts->gpg_sign, key, value);
|
2012-01-12 02:15:57 +08:00
|
|
|
else if (!strcmp(key, "options.strategy-option")) {
|
|
|
|
|
ALLOC_GROW(opts->xopts, opts->xopts_nr + 1, opts->xopts_alloc);
|
|
|
|
|
opts->xopts[opts->xopts_nr++] = xstrdup(value);
|
2017-08-02 18:44:19 +08:00
|
|
|
} else if (!strcmp(key, "options.allow-rerere-auto"))
|
|
|
|
|
opts->allow_rerere_auto =
|
|
|
|
|
git_config_bool_or_int(key, value, &error_flag) ?
|
|
|
|
|
RERERE_AUTOUPDATE : RERERE_NOAUTOUPDATE;
|
2019-04-17 18:23:29 +08:00
|
|
|
else if (!strcmp(key, "options.default-msg-cleanup")) {
|
|
|
|
|
opts->explicit_cleanup = 1;
|
|
|
|
|
opts->default_msg_cleanup = get_cleanup_mode(value, 1);
|
|
|
|
|
} else
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("invalid key: %s"), key);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
if (!error_flag)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("invalid value for %s: %s"), key, value);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-28 20:10:40 +08:00
|
|
|
void parse_strategy_opts(struct replay_opts *opts, char *raw_opts)
|
2017-01-02 23:28:30 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
2018-08-28 20:10:40 +08:00
|
|
|
char *strategy_opts_string = raw_opts;
|
2017-01-02 23:28:30 +08:00
|
|
|
|
2018-06-27 23:48:04 +08:00
|
|
|
if (*strategy_opts_string == ' ')
|
|
|
|
|
strategy_opts_string++;
|
2018-08-28 20:10:40 +08:00
|
|
|
|
2018-06-27 23:48:04 +08:00
|
|
|
opts->xopts_nr = split_cmdline(strategy_opts_string,
|
|
|
|
|
(const char ***)&opts->xopts);
|
2017-01-02 23:28:30 +08:00
|
|
|
for (i = 0; i < opts->xopts_nr; i++) {
|
|
|
|
|
const char *arg = opts->xopts[i];
|
|
|
|
|
|
|
|
|
|
skip_prefix(arg, "--", &arg);
|
|
|
|
|
opts->xopts[i] = xstrdup(arg);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-28 20:10:40 +08:00
|
|
|
static void read_strategy_opts(struct replay_opts *opts, struct strbuf *buf)
|
|
|
|
|
{
|
|
|
|
|
strbuf_reset(buf);
|
|
|
|
|
if (!read_oneliner(buf, rebase_path_strategy(), 0))
|
|
|
|
|
return;
|
|
|
|
|
opts->strategy = strbuf_detach(buf, NULL);
|
|
|
|
|
if (!read_oneliner(buf, rebase_path_strategy_opts(), 0))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
parse_strategy_opts(opts, buf->buf);
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-14 21:17:16 +08:00
|
|
|
static int read_populate_opts(struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2016-10-21 20:25:12 +08:00
|
|
|
if (is_rebase_i(opts)) {
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
if (read_oneliner(&buf, rebase_path_gpg_sign_opt(), 1)) {
|
|
|
|
|
if (!starts_with(buf.buf, "-S"))
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
else {
|
|
|
|
|
free(opts->gpg_sign);
|
|
|
|
|
opts->gpg_sign = xstrdup(buf.buf + 2);
|
|
|
|
|
}
|
2017-08-02 18:44:17 +08:00
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (read_oneliner(&buf, rebase_path_allow_rerere_autoupdate(), 1)) {
|
|
|
|
|
if (!strcmp(buf.buf, "--rerere-autoupdate"))
|
|
|
|
|
opts->allow_rerere_auto = RERERE_AUTOUPDATE;
|
|
|
|
|
else if (!strcmp(buf.buf, "--no-rerere-autoupdate"))
|
|
|
|
|
opts->allow_rerere_auto = RERERE_NOAUTOUPDATE;
|
|
|
|
|
strbuf_reset(&buf);
|
2016-10-21 20:25:12 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:26:53 +08:00
|
|
|
if (file_exists(rebase_path_verbose()))
|
|
|
|
|
opts->verbose = 1;
|
|
|
|
|
|
git-rebase, sequencer: extend --quiet option for the interactive machinery
While 'quiet' and 'interactive' may sound like antonyms, the interactive
machinery actually has logic that implements several
interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
which won't pop up an editor. The rewrite of interactive rebase in C
added a quiet option, though it only turns stats off. Since we want to
make the interactive machinery also take over for git-rebase--merge, it
should fully implement the --quiet option.
git-rebase--interactive was already somewhat quieter than
git-rebase--merge and git-rebase--am, possibly because cherry-pick has
just traditionally been quieter. As such, we only drop a few
informational messages -- "Rebasing (n/m)" and "Successfully rebased..."
Also, for simplicity, remove the differences in how quiet and verbose
options were recorded. Having one be signalled by the presence of a
"verbose" file in the state_dir, while the other was signalled by the
contents of a "quiet" file was just weirdly inconsistent. (This
inconsistency pre-dated the rewrite into C.) Make them consistent by
having them both key off the presence of the file.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:36 +08:00
|
|
|
if (file_exists(rebase_path_quiet()))
|
|
|
|
|
opts->quiet = 1;
|
|
|
|
|
|
2018-03-20 19:10:55 +08:00
|
|
|
if (file_exists(rebase_path_signoff())) {
|
|
|
|
|
opts->allow_ff = 0;
|
|
|
|
|
opts->signoff = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-11 03:04:58 +08:00
|
|
|
if (file_exists(rebase_path_reschedule_failed_exec()))
|
|
|
|
|
opts->reschedule_failed_exec = 1;
|
|
|
|
|
|
2017-01-02 23:28:30 +08:00
|
|
|
read_strategy_opts(opts, &buf);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
2018-04-28 04:48:21 +08:00
|
|
|
if (read_oneliner(&opts->current_fixups,
|
|
|
|
|
rebase_path_current_fixups(), 1)) {
|
|
|
|
|
const char *p = opts->current_fixups.buf;
|
|
|
|
|
opts->current_fixup_count = 1;
|
|
|
|
|
while ((p = strchr(p, '\n'))) {
|
|
|
|
|
opts->current_fixup_count++;
|
|
|
|
|
p++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: learn about the special "fake root commit" handling
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists
and contains a commit name, the sequencer will compare the HEAD to said
root commit, and if identical, a new root commit will be created.
While converting scripted code into proper, portable C, we also do away
with the old "amend with an empty commit message, then cherry-pick
without committing, then amend again" dance and replace it with code
that uses the internal API properly to do exactly what we want: create a
new root commit.
To keep the implementation simple, we always spawn `git commit` to create
new root commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:17 +08:00
|
|
|
if (read_oneliner(&buf, rebase_path_squash_onto(), 0)) {
|
|
|
|
|
if (get_oid_hex(buf.buf, &opts->squash_onto) < 0)
|
|
|
|
|
return error(_("unusable squash-onto"));
|
|
|
|
|
opts->have_squash_onto = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-21 20:25:04 +08:00
|
|
|
return 0;
|
2016-10-21 20:25:12 +08:00
|
|
|
}
|
2016-10-21 20:25:04 +08:00
|
|
|
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 17:38:57 +08:00
|
|
|
if (!file_exists(git_path_opts_file()))
|
sequencer: lib'ify read_populate_opts()
Instead of dying there, let the caller high up in the callchain notice
the error and handle it (by dying, still).
The only caller of read_populate_opts(), sequencer_continue() can
already return errors, so its caller must be already prepared to
handle error returns, and with this step, we make it notice an error
return from this function.
So this is a safe conversion to make read_populate_opts() callable
from new callers that want it not to die, without changing the
external behaviour of anything existing.
Note that the function git_config_from_file(), called from
read_populate_opts(), can currently still die() (in git_parse_source(),
because the do_config_from_file() function sets die_on_error = 1). We do
not try to fix that here, as it would have larger ramifications on the
config code, and we also assume that we write the opts file
programmatically, hence any parse errors would be bugs.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-09 22:37:27 +08:00
|
|
|
return 0;
|
|
|
|
|
/*
|
|
|
|
|
* The function git_parse_source(), called from git_config_from_file(),
|
|
|
|
|
* may die() in case of a syntactically incorrect file. We do not care
|
|
|
|
|
* about this case, though, because we wrote that file ourselves, so we
|
|
|
|
|
* are pretty certain that it is syntactically correct.
|
|
|
|
|
*/
|
2016-10-14 21:17:16 +08:00
|
|
|
if (git_config_from_file(populate_opts_cb, git_path_opts_file(), opts) < 0)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("malformed options sheet: '%s'"),
|
sequencer: lib'ify read_populate_opts()
Instead of dying there, let the caller high up in the callchain notice
the error and handle it (by dying, still).
The only caller of read_populate_opts(), sequencer_continue() can
already return errors, so its caller must be already prepared to
handle error returns, and with this step, we make it notice an error
return from this function.
So this is a safe conversion to make read_populate_opts() callable
from new callers that want it not to die, without changing the
external behaviour of anything existing.
Note that the function git_config_from_file(), called from
read_populate_opts(), can currently still die() (in git_parse_source(),
because the do_config_from_file() function sets die_on_error = 1). We do
not try to fix that here, as it would have larger ramifications on the
config code, and we also assume that we write the opts file
programmatically, hence any parse errors would be bugs.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-09 22:37:27 +08:00
|
|
|
git_path_opts_file());
|
|
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-08-28 20:10:40 +08:00
|
|
|
static void write_strategy_opts(struct replay_opts *opts)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < opts->xopts_nr; ++i)
|
|
|
|
|
strbuf_addf(&buf, " --%s", opts->xopts[i]);
|
|
|
|
|
|
|
|
|
|
write_file(rebase_path_strategy_opts(), "%s\n", buf.buf);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int write_basic_state(struct replay_opts *opts, const char *head_name,
|
2019-04-17 22:30:39 +08:00
|
|
|
struct commit *onto, const char *orig_head)
|
2018-08-28 20:10:40 +08:00
|
|
|
{
|
|
|
|
|
const char *quiet = getenv("GIT_QUIET");
|
|
|
|
|
|
|
|
|
|
if (head_name)
|
|
|
|
|
write_file(rebase_path_head_name(), "%s\n", head_name);
|
|
|
|
|
if (onto)
|
2019-04-17 22:30:39 +08:00
|
|
|
write_file(rebase_path_onto(), "%s\n",
|
|
|
|
|
oid_to_hex(&onto->object.oid));
|
2018-08-28 20:10:40 +08:00
|
|
|
if (orig_head)
|
|
|
|
|
write_file(rebase_path_orig_head(), "%s\n", orig_head);
|
|
|
|
|
|
|
|
|
|
if (quiet)
|
|
|
|
|
write_file(rebase_path_quiet(), "%s\n", quiet);
|
|
|
|
|
if (opts->verbose)
|
2018-10-25 17:38:54 +08:00
|
|
|
write_file(rebase_path_verbose(), "%s", "");
|
2018-08-28 20:10:40 +08:00
|
|
|
if (opts->strategy)
|
|
|
|
|
write_file(rebase_path_strategy(), "%s\n", opts->strategy);
|
|
|
|
|
if (opts->xopts_nr > 0)
|
|
|
|
|
write_strategy_opts(opts);
|
|
|
|
|
|
|
|
|
|
if (opts->allow_rerere_auto == RERERE_AUTOUPDATE)
|
|
|
|
|
write_file(rebase_path_allow_rerere_autoupdate(), "--rerere-autoupdate\n");
|
|
|
|
|
else if (opts->allow_rerere_auto == RERERE_NOAUTOUPDATE)
|
|
|
|
|
write_file(rebase_path_allow_rerere_autoupdate(), "--no-rerere-autoupdate\n");
|
|
|
|
|
|
|
|
|
|
if (opts->gpg_sign)
|
|
|
|
|
write_file(rebase_path_gpg_sign_opt(), "-S%s\n", opts->gpg_sign);
|
|
|
|
|
if (opts->signoff)
|
|
|
|
|
write_file(rebase_path_signoff(), "--signoff\n");
|
2018-12-11 03:04:58 +08:00
|
|
|
if (opts->reschedule_failed_exec)
|
|
|
|
|
write_file(rebase_path_reschedule_failed_exec(), "%s", "");
|
2018-08-28 20:10:40 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
static int walk_revs_populate_todo(struct todo_list *todo_list,
|
2012-01-12 02:15:57 +08:00
|
|
|
struct replay_opts *opts)
|
|
|
|
|
{
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
enum todo_command command = opts->action == REPLAY_PICK ?
|
|
|
|
|
TODO_PICK : TODO_REVERT;
|
2017-01-02 23:27:15 +08:00
|
|
|
const char *command_string = todo_command_info[command].str;
|
2012-01-12 02:15:57 +08:00
|
|
|
struct commit *commit;
|
|
|
|
|
|
2016-09-09 22:37:15 +08:00
|
|
|
if (prepare_revs(opts))
|
|
|
|
|
return -1;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
while ((commit = get_revision(opts->revs))) {
|
|
|
|
|
struct todo_item *item = append_new_todo(todo_list);
|
|
|
|
|
const char *commit_buffer = get_commit_buffer(commit, NULL);
|
|
|
|
|
const char *subject;
|
|
|
|
|
int subject_len;
|
|
|
|
|
|
|
|
|
|
item->command = command;
|
|
|
|
|
item->commit = commit;
|
2019-01-29 23:01:46 +08:00
|
|
|
item->arg_offset = 0;
|
2016-10-21 20:25:00 +08:00
|
|
|
item->arg_len = 0;
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
item->offset_in_buf = todo_list->buf.len;
|
|
|
|
|
subject_len = find_commit_subject(commit_buffer, &subject);
|
|
|
|
|
strbuf_addf(&todo_list->buf, "%s %s %.*s\n", command_string,
|
|
|
|
|
short_commit_name(commit), subject_len, subject);
|
|
|
|
|
unuse_commit_buffer(commit, commit_buffer);
|
|
|
|
|
}
|
2018-07-10 03:48:19 +08:00
|
|
|
|
|
|
|
|
if (!todo_list->nr)
|
|
|
|
|
return error(_("empty commit set passed"));
|
|
|
|
|
|
2016-09-09 22:37:15 +08:00
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2019-07-02 17:11:25 +08:00
|
|
|
static int create_seq_dir(struct repository *r)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2019-07-02 17:11:25 +08:00
|
|
|
enum replay_action action;
|
|
|
|
|
const char *in_progress_error = NULL;
|
|
|
|
|
const char *in_progress_advice = NULL;
|
2019-07-02 17:11:29 +08:00
|
|
|
unsigned int advise_skip = file_exists(git_path_revert_head(r)) ||
|
|
|
|
|
file_exists(git_path_cherry_pick_head(r));
|
2019-07-02 17:11:25 +08:00
|
|
|
|
|
|
|
|
if (!sequencer_get_last_command(r, &action)) {
|
|
|
|
|
switch (action) {
|
|
|
|
|
case REPLAY_REVERT:
|
|
|
|
|
in_progress_error = _("revert is already in progress");
|
|
|
|
|
in_progress_advice =
|
2019-07-02 17:11:29 +08:00
|
|
|
_("try \"git revert (--continue | %s--abort | --quit)\"");
|
2019-07-02 17:11:25 +08:00
|
|
|
break;
|
|
|
|
|
case REPLAY_PICK:
|
|
|
|
|
in_progress_error = _("cherry-pick is already in progress");
|
|
|
|
|
in_progress_advice =
|
2019-07-02 17:11:29 +08:00
|
|
|
_("try \"git cherry-pick (--continue | %s--abort | --quit)\"");
|
2019-07-02 17:11:25 +08:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
BUG("unexpected action in create_seq_dir");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (in_progress_error) {
|
|
|
|
|
error("%s", in_progress_error);
|
|
|
|
|
if (advice_sequencer_in_use)
|
2019-07-02 17:11:29 +08:00
|
|
|
advise(in_progress_advice,
|
|
|
|
|
advise_skip ? "--skip | " : "");
|
2012-01-12 02:15:57 +08:00
|
|
|
return -1;
|
2019-07-02 17:11:25 +08:00
|
|
|
}
|
|
|
|
|
if (mkdir(git_path_seq_dir(), 0777) < 0)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error_errno(_("could not create sequencer directory '%s'"),
|
2016-09-09 22:37:44 +08:00
|
|
|
git_path_seq_dir());
|
2019-07-02 17:11:25 +08:00
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-09 22:37:47 +08:00
|
|
|
static int save_head(const char *head)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2018-02-28 05:30:09 +08:00
|
|
|
struct lock_file head_lock = LOCK_INIT;
|
2012-01-12 02:15:57 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
int fd;
|
2017-08-31 02:20:14 +08:00
|
|
|
ssize_t written;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2016-09-09 22:37:47 +08:00
|
|
|
fd = hold_lock_file_for_update(&head_lock, git_path_head_file(), 0);
|
2018-03-01 03:07:58 +08:00
|
|
|
if (fd < 0)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error_errno(_("could not lock HEAD"));
|
2012-01-12 02:15:57 +08:00
|
|
|
strbuf_addf(&buf, "%s\n", head);
|
2017-08-31 02:20:14 +08:00
|
|
|
written = write_in_full(fd, buf.buf, buf.len);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
if (written < 0) {
|
2018-04-25 20:28:17 +08:00
|
|
|
error_errno(_("could not write to '%s'"), git_path_head_file());
|
2016-09-09 22:37:47 +08:00
|
|
|
rollback_lock_file(&head_lock);
|
2018-04-25 20:28:17 +08:00
|
|
|
return -1;
|
2016-09-09 22:37:47 +08:00
|
|
|
}
|
2018-03-01 03:07:58 +08:00
|
|
|
if (commit_lock_file(&head_lock) < 0)
|
|
|
|
|
return error(_("failed to finalize '%s'"), git_path_head_file());
|
2016-09-09 22:37:47 +08:00
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2016-12-08 05:51:32 +08:00
|
|
|
static int rollback_is_safe(void)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
struct object_id expected_head, actual_head;
|
|
|
|
|
|
|
|
|
|
if (strbuf_read_file(&sb, git_path_abort_safety_file(), 0) >= 0) {
|
|
|
|
|
strbuf_trim(&sb);
|
|
|
|
|
if (get_oid_hex(sb.buf, &expected_head)) {
|
|
|
|
|
strbuf_release(&sb);
|
|
|
|
|
die(_("could not parse %s"), git_path_abort_safety_file());
|
|
|
|
|
}
|
|
|
|
|
strbuf_release(&sb);
|
|
|
|
|
}
|
|
|
|
|
else if (errno == ENOENT)
|
|
|
|
|
oidclr(&expected_head);
|
|
|
|
|
else
|
|
|
|
|
die_errno(_("could not read '%s'"), git_path_abort_safety_file());
|
|
|
|
|
|
|
|
|
|
if (get_oid("HEAD", &actual_head))
|
|
|
|
|
oidclr(&actual_head);
|
|
|
|
|
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
return oideq(&actual_head, &expected_head);
|
2016-12-08 05:51:32 +08:00
|
|
|
}
|
|
|
|
|
|
2019-07-02 17:11:26 +08:00
|
|
|
static int reset_merge(const struct object_id *oid)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2019-07-02 17:11:27 +08:00
|
|
|
int ret;
|
|
|
|
|
struct argv_array argv = ARGV_ARRAY_INIT;
|
2016-12-08 05:51:32 +08:00
|
|
|
|
2019-07-02 17:11:27 +08:00
|
|
|
argv_array_pushl(&argv, "reset", "--merge", NULL);
|
|
|
|
|
|
|
|
|
|
if (!is_null_oid(oid))
|
|
|
|
|
argv_array_push(&argv, oid_to_hex(oid));
|
2016-12-08 05:51:32 +08:00
|
|
|
|
2019-07-02 17:11:27 +08:00
|
|
|
ret = run_command_v_opt(argv.argv, RUN_GIT_CMD);
|
|
|
|
|
argv_array_clear(&argv);
|
|
|
|
|
|
|
|
|
|
return ret;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int rollback_single_pick(struct repository *r)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2017-07-14 07:49:22 +08:00
|
|
|
struct object_id head_oid;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
if (!file_exists(git_path_cherry_pick_head(r)) &&
|
|
|
|
|
!file_exists(git_path_revert_head(r)))
|
2012-01-12 02:15:57 +08:00
|
|
|
return error(_("no cherry-pick or revert in progress"));
|
2017-10-16 06:06:56 +08:00
|
|
|
if (read_ref_full("HEAD", 0, &head_oid, NULL))
|
2012-01-12 02:15:57 +08:00
|
|
|
return error(_("cannot resolve HEAD"));
|
2017-07-14 07:49:22 +08:00
|
|
|
if (is_null_oid(&head_oid))
|
2012-01-12 02:15:57 +08:00
|
|
|
return error(_("cannot abort from a branch yet to be born"));
|
2019-07-02 17:11:26 +08:00
|
|
|
return reset_merge(&head_oid);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2019-07-02 17:11:28 +08:00
|
|
|
static int skip_single_pick(void)
|
|
|
|
|
{
|
|
|
|
|
struct object_id head;
|
|
|
|
|
|
|
|
|
|
if (read_ref_full("HEAD", 0, &head, NULL))
|
|
|
|
|
return error(_("cannot resolve HEAD"));
|
|
|
|
|
return reset_merge(&head);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
int sequencer_rollback(struct repository *r, struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
|
|
|
|
FILE *f;
|
2017-07-14 07:49:22 +08:00
|
|
|
struct object_id oid;
|
2012-01-12 02:15:57 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2017-07-14 07:49:22 +08:00
|
|
|
const char *p;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 17:38:57 +08:00
|
|
|
f = fopen(git_path_head_file(), "r");
|
2012-01-12 02:15:57 +08:00
|
|
|
if (!f && errno == ENOENT) {
|
|
|
|
|
/*
|
|
|
|
|
* There is no multiple-cherry-pick in progress.
|
|
|
|
|
* If CHERRY_PICK_HEAD or REVERT_HEAD indicates
|
|
|
|
|
* a single-cherry-pick in progress, abort that.
|
|
|
|
|
*/
|
2018-11-10 13:48:57 +08:00
|
|
|
return rollback_single_pick(r);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
if (!f)
|
2016-10-21 20:26:21 +08:00
|
|
|
return error_errno(_("cannot open '%s'"), git_path_head_file());
|
2016-01-14 07:31:17 +08:00
|
|
|
if (strbuf_getline_lf(&buf, f)) {
|
2016-10-21 20:26:21 +08:00
|
|
|
error(_("cannot read '%s': %s"), git_path_head_file(),
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 17:38:57 +08:00
|
|
|
ferror(f) ? strerror(errno) : _("unexpected end of file"));
|
2012-01-12 02:15:57 +08:00
|
|
|
fclose(f);
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
fclose(f);
|
2017-07-14 07:49:22 +08:00
|
|
|
if (parse_oid_hex(buf.buf, &oid, &p) || *p != '\0') {
|
2012-01-12 02:15:57 +08:00
|
|
|
error(_("stored pre-cherry-pick HEAD file '%s' is corrupt"),
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 17:38:57 +08:00
|
|
|
git_path_head_file());
|
2012-01-12 02:15:57 +08:00
|
|
|
goto fail;
|
|
|
|
|
}
|
2017-07-14 07:49:22 +08:00
|
|
|
if (is_null_oid(&oid)) {
|
2016-06-06 21:23:54 +08:00
|
|
|
error(_("cannot abort from a branch yet to be born"));
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
2016-12-08 05:51:32 +08:00
|
|
|
|
|
|
|
|
if (!rollback_is_safe()) {
|
|
|
|
|
/* Do not error, just do not rollback */
|
|
|
|
|
warning(_("You seem to have moved HEAD. "
|
|
|
|
|
"Not rewinding, check your HEAD!"));
|
|
|
|
|
} else
|
2019-07-02 17:11:26 +08:00
|
|
|
if (reset_merge(&oid))
|
2012-01-12 02:15:57 +08:00
|
|
|
goto fail;
|
|
|
|
|
strbuf_release(&buf);
|
2016-10-21 20:24:55 +08:00
|
|
|
return sequencer_remove_state(opts);
|
2012-01-12 02:15:57 +08:00
|
|
|
fail:
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-02 17:11:28 +08:00
|
|
|
int sequencer_skip(struct repository *r, struct replay_opts *opts)
|
|
|
|
|
{
|
|
|
|
|
enum replay_action action = -1;
|
|
|
|
|
sequencer_get_last_command(r, &action);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check whether the subcommand requested to skip the commit is actually
|
|
|
|
|
* in progress and that it's safe to skip the commit.
|
|
|
|
|
*
|
|
|
|
|
* opts->action tells us which subcommand requested to skip the commit.
|
|
|
|
|
* If the corresponding .git/<ACTION>_HEAD exists, we know that the
|
|
|
|
|
* action is in progress and we can skip the commit.
|
|
|
|
|
*
|
|
|
|
|
* Otherwise we check that the last instruction was related to the
|
|
|
|
|
* particular subcommand we're trying to execute and barf if that's not
|
|
|
|
|
* the case.
|
|
|
|
|
*
|
|
|
|
|
* Finally we check that the rollback is "safe", i.e., has the HEAD
|
|
|
|
|
* moved? In this case, it doesn't make sense to "reset the merge" and
|
|
|
|
|
* "skip the commit" as the user already handled this by committing. But
|
|
|
|
|
* we'd not want to barf here, instead give advice on how to proceed. We
|
|
|
|
|
* only need to check that when .git/<ACTION>_HEAD doesn't exist because
|
|
|
|
|
* it gets removed when the user commits, so if it still exists we're
|
|
|
|
|
* sure the user can't have committed before.
|
|
|
|
|
*/
|
|
|
|
|
switch (opts->action) {
|
|
|
|
|
case REPLAY_REVERT:
|
|
|
|
|
if (!file_exists(git_path_revert_head(r))) {
|
|
|
|
|
if (action != REPLAY_REVERT)
|
|
|
|
|
return error(_("no revert in progress"));
|
|
|
|
|
if (!rollback_is_safe())
|
|
|
|
|
goto give_advice;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case REPLAY_PICK:
|
|
|
|
|
if (!file_exists(git_path_cherry_pick_head(r))) {
|
|
|
|
|
if (action != REPLAY_PICK)
|
|
|
|
|
return error(_("no cherry-pick in progress"));
|
|
|
|
|
if (!rollback_is_safe())
|
|
|
|
|
goto give_advice;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
BUG("unexpected action in sequencer_skip");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (skip_single_pick())
|
|
|
|
|
return error(_("failed to skip the commit"));
|
|
|
|
|
if (!is_directory(git_path_seq_dir()))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
return sequencer_continue(r, opts);
|
|
|
|
|
|
|
|
|
|
give_advice:
|
|
|
|
|
error(_("there is nothing to skip"));
|
|
|
|
|
|
|
|
|
|
if (advice_resolve_conflict) {
|
|
|
|
|
advise(_("have you committed already?\n"
|
|
|
|
|
"try \"git %s --continue\""),
|
|
|
|
|
action == REPLAY_REVERT ? "revert" : "cherry-pick");
|
|
|
|
|
}
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
static int save_todo(struct todo_list *todo_list, struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
2018-02-28 05:30:09 +08:00
|
|
|
struct lock_file todo_lock = LOCK_INIT;
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
const char *todo_path = get_todo_path(opts);
|
|
|
|
|
int next = todo_list->current, offset, fd;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2017-01-02 23:26:28 +08:00
|
|
|
/*
|
|
|
|
|
* rebase -i writes "git-rebase-todo" without the currently executing
|
|
|
|
|
* command, appending it to "done" instead.
|
|
|
|
|
*/
|
|
|
|
|
if (is_rebase_i(opts))
|
|
|
|
|
next++;
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
fd = hold_lock_file_for_update(&todo_lock, todo_path, 0);
|
2016-09-09 22:37:50 +08:00
|
|
|
if (fd < 0)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error_errno(_("could not lock '%s'"), todo_path);
|
2018-04-25 20:28:29 +08:00
|
|
|
offset = get_item_line_offset(todo_list, next);
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
if (write_in_full(fd, todo_list->buf.buf + offset,
|
|
|
|
|
todo_list->buf.len - offset) < 0)
|
2016-10-21 20:26:25 +08:00
|
|
|
return error_errno(_("could not write to '%s'"), todo_path);
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
if (commit_lock_file(&todo_lock) < 0)
|
2018-03-01 03:07:58 +08:00
|
|
|
return error(_("failed to finalize '%s'"), todo_path);
|
2017-01-02 23:27:00 +08:00
|
|
|
|
2018-04-25 20:28:29 +08:00
|
|
|
if (is_rebase_i(opts) && next > 0) {
|
|
|
|
|
const char *done = rebase_path_done();
|
|
|
|
|
int fd = open(done, O_CREAT | O_WRONLY | O_APPEND, 0666);
|
|
|
|
|
int ret = 0;
|
2017-01-02 23:27:00 +08:00
|
|
|
|
2018-04-25 20:28:29 +08:00
|
|
|
if (fd < 0)
|
|
|
|
|
return 0;
|
|
|
|
|
if (write_in_full(fd, get_item_line(todo_list, next - 1),
|
|
|
|
|
get_item_line_length(todo_list, next - 1))
|
|
|
|
|
< 0)
|
|
|
|
|
ret = error_errno(_("could not write to '%s'"), done);
|
|
|
|
|
if (close(fd) < 0)
|
|
|
|
|
ret = error_errno(_("failed to finalize '%s'"), done);
|
|
|
|
|
return ret;
|
2017-01-02 23:27:00 +08:00
|
|
|
}
|
2016-09-09 22:37:50 +08:00
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-09 22:37:53 +08:00
|
|
|
static int save_opts(struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 17:38:57 +08:00
|
|
|
const char *opts_file = git_path_opts_file();
|
2016-09-09 22:37:53 +08:00
|
|
|
int res = 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
if (opts->no_commit)
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.no-commit", "true");
|
2012-01-12 02:15:57 +08:00
|
|
|
if (opts->edit)
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.edit", "true");
|
2019-03-14 02:26:15 +08:00
|
|
|
if (opts->allow_empty)
|
|
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.allow-empty", "true");
|
|
|
|
|
if (opts->allow_empty_message)
|
|
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.allow-empty-message", "true");
|
|
|
|
|
if (opts->keep_redundant_commits)
|
|
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.keep-redundant-commits", "true");
|
2012-01-12 02:15:57 +08:00
|
|
|
if (opts->signoff)
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.signoff", "true");
|
2012-01-12 02:15:57 +08:00
|
|
|
if (opts->record_origin)
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.record-origin", "true");
|
2012-01-12 02:15:57 +08:00
|
|
|
if (opts->allow_ff)
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.allow-ff", "true");
|
2012-01-12 02:15:57 +08:00
|
|
|
if (opts->mainline) {
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
strbuf_addf(&buf, "%d", opts->mainline);
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.mainline", buf.buf);
|
2012-01-12 02:15:57 +08:00
|
|
|
strbuf_release(&buf);
|
|
|
|
|
}
|
|
|
|
|
if (opts->strategy)
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.strategy", opts->strategy);
|
2014-01-24 08:50:58 +08:00
|
|
|
if (opts->gpg_sign)
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.gpg-sign", opts->gpg_sign);
|
2012-01-12 02:15:57 +08:00
|
|
|
if (opts->xopts) {
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < opts->xopts_nr; i++)
|
2016-09-09 22:37:53 +08:00
|
|
|
res |= git_config_set_multivar_in_file_gently(opts_file,
|
2019-03-14 02:26:13 +08:00
|
|
|
"options.strategy-option",
|
|
|
|
|
opts->xopts[i], "^$", 0);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
2017-08-02 18:44:19 +08:00
|
|
|
if (opts->allow_rerere_auto)
|
2019-03-14 02:26:13 +08:00
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.allow-rerere-auto",
|
|
|
|
|
opts->allow_rerere_auto == RERERE_AUTOUPDATE ?
|
|
|
|
|
"true" : "false");
|
2019-04-17 18:23:29 +08:00
|
|
|
|
|
|
|
|
if (opts->explicit_cleanup)
|
|
|
|
|
res |= git_config_set_in_file_gently(opts_file,
|
|
|
|
|
"options.default-msg-cleanup",
|
|
|
|
|
describe_cleanup_mode(opts->default_msg_cleanup));
|
2016-09-09 22:37:53 +08:00
|
|
|
return res;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int make_patch(struct repository *r,
|
|
|
|
|
struct commit *commit,
|
|
|
|
|
struct replay_opts *opts)
|
2017-01-02 23:26:43 +08:00
|
|
|
{
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
struct rev_info log_tree_opt;
|
|
|
|
|
const char *subject, *p;
|
|
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
|
|
p = short_commit_name(commit);
|
|
|
|
|
if (write_message(p, strlen(p), rebase_path_stopped_sha(), 1) < 0)
|
|
|
|
|
return -1;
|
2018-02-11 17:43:28 +08:00
|
|
|
if (update_ref("rebase", "REBASE_HEAD", &commit->object.oid,
|
|
|
|
|
NULL, REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR))
|
|
|
|
|
res |= error(_("could not update %s"), "REBASE_HEAD");
|
2017-01-02 23:26:43 +08:00
|
|
|
|
|
|
|
|
strbuf_addf(&buf, "%s/patch", get_dir(opts));
|
|
|
|
|
memset(&log_tree_opt, 0, sizeof(log_tree_opt));
|
2018-11-10 13:48:56 +08:00
|
|
|
repo_init_revisions(r, &log_tree_opt, NULL);
|
2017-01-02 23:26:43 +08:00
|
|
|
log_tree_opt.abbrev = 0;
|
|
|
|
|
log_tree_opt.diff = 1;
|
|
|
|
|
log_tree_opt.diffopt.output_format = DIFF_FORMAT_PATCH;
|
|
|
|
|
log_tree_opt.disable_stdin = 1;
|
|
|
|
|
log_tree_opt.no_commit_id = 1;
|
|
|
|
|
log_tree_opt.diffopt.file = fopen(buf.buf, "w");
|
|
|
|
|
log_tree_opt.diffopt.use_color = GIT_COLOR_NEVER;
|
|
|
|
|
if (!log_tree_opt.diffopt.file)
|
|
|
|
|
res |= error_errno(_("could not open '%s'"), buf.buf);
|
|
|
|
|
else {
|
|
|
|
|
res |= log_tree_commit(&log_tree_opt, commit);
|
|
|
|
|
fclose(log_tree_opt.diffopt.file);
|
|
|
|
|
}
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
|
|
|
|
|
strbuf_addf(&buf, "%s/message", get_dir(opts));
|
|
|
|
|
if (!file_exists(buf.buf)) {
|
|
|
|
|
const char *commit_buffer = get_commit_buffer(commit, NULL);
|
|
|
|
|
find_commit_subject(commit_buffer, &subject);
|
|
|
|
|
res |= write_message(subject, strlen(subject), buf.buf, 1);
|
|
|
|
|
unuse_commit_buffer(commit, commit_buffer);
|
|
|
|
|
}
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int intend_to_amend(void)
|
|
|
|
|
{
|
2017-07-14 07:49:22 +08:00
|
|
|
struct object_id head;
|
2017-01-02 23:26:43 +08:00
|
|
|
char *p;
|
|
|
|
|
|
2017-07-14 07:49:22 +08:00
|
|
|
if (get_oid("HEAD", &head))
|
2017-01-02 23:26:43 +08:00
|
|
|
return error(_("cannot read HEAD"));
|
|
|
|
|
|
2017-07-14 07:49:22 +08:00
|
|
|
p = oid_to_hex(&head);
|
2017-01-02 23:26:43 +08:00
|
|
|
return write_message(p, strlen(p), rebase_path_amend(), 1);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int error_with_patch(struct repository *r,
|
|
|
|
|
struct commit *commit,
|
|
|
|
|
const char *subject, int subject_len,
|
|
|
|
|
struct replay_opts *opts,
|
|
|
|
|
int exit_code, int to_amend)
|
2017-01-02 23:26:43 +08:00
|
|
|
{
|
2018-08-15 17:39:35 +08:00
|
|
|
if (commit) {
|
2018-11-10 13:48:56 +08:00
|
|
|
if (make_patch(r, commit, opts))
|
2018-08-15 17:39:35 +08:00
|
|
|
return -1;
|
2018-08-21 03:41:33 +08:00
|
|
|
} else if (copy_file(rebase_path_message(),
|
2018-11-10 13:48:56 +08:00
|
|
|
git_path_merge_msg(r), 0666))
|
2018-08-15 17:39:35 +08:00
|
|
|
return error(_("unable to copy '%s' to '%s'"),
|
2018-11-10 13:48:56 +08:00
|
|
|
git_path_merge_msg(r), rebase_path_message());
|
2017-01-02 23:26:43 +08:00
|
|
|
|
|
|
|
|
if (to_amend) {
|
|
|
|
|
if (intend_to_amend())
|
|
|
|
|
return -1;
|
|
|
|
|
|
2018-07-21 15:49:38 +08:00
|
|
|
fprintf(stderr,
|
|
|
|
|
_("You can amend the commit now, with\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git commit --amend %s\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Once you are satisfied with your changes, run\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git rebase --continue\n"),
|
|
|
|
|
gpg_sign_opt_quoted(opts));
|
2018-08-15 17:39:35 +08:00
|
|
|
} else if (exit_code) {
|
|
|
|
|
if (commit)
|
2018-08-21 03:41:33 +08:00
|
|
|
fprintf_ln(stderr, _("Could not apply %s... %.*s"),
|
|
|
|
|
short_commit_name(commit), subject_len, subject);
|
2018-08-15 17:39:35 +08:00
|
|
|
else
|
|
|
|
|
/*
|
|
|
|
|
* We don't have the hash of the parent so
|
|
|
|
|
* just print the line from the todo file.
|
|
|
|
|
*/
|
2018-08-21 03:41:33 +08:00
|
|
|
fprintf_ln(stderr, _("Could not merge %.*s"),
|
|
|
|
|
subject_len, subject);
|
2018-08-15 17:39:35 +08:00
|
|
|
}
|
2017-01-02 23:26:43 +08:00
|
|
|
|
|
|
|
|
return exit_code;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int error_failed_squash(struct repository *r,
|
|
|
|
|
struct commit *commit,
|
|
|
|
|
struct replay_opts *opts,
|
|
|
|
|
int subject_len,
|
|
|
|
|
const char *subject)
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
{
|
2018-04-28 04:48:21 +08:00
|
|
|
if (copy_file(rebase_path_message(), rebase_path_squash_msg(), 0666))
|
|
|
|
|
return error(_("could not copy '%s' to '%s'"),
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
rebase_path_squash_msg(), rebase_path_message());
|
2018-11-10 13:48:56 +08:00
|
|
|
unlink(git_path_merge_msg(r));
|
|
|
|
|
if (copy_file(git_path_merge_msg(r), rebase_path_message(), 0666))
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
return error(_("could not copy '%s' to '%s'"),
|
2018-05-18 06:51:51 +08:00
|
|
|
rebase_path_message(),
|
2018-11-10 13:48:56 +08:00
|
|
|
git_path_merge_msg(r));
|
|
|
|
|
return error_with_patch(r, commit, subject, subject_len, opts, 1, 0);
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_exec(struct repository *r, const char *command_line)
|
2017-01-02 23:26:47 +08:00
|
|
|
{
|
2017-11-01 07:07:33 +08:00
|
|
|
struct argv_array child_env = ARGV_ARRAY_INIT;
|
2017-01-02 23:26:47 +08:00
|
|
|
const char *child_argv[] = { NULL, NULL };
|
|
|
|
|
int dirty, status;
|
|
|
|
|
|
|
|
|
|
fprintf(stderr, "Executing: %s\n", command_line);
|
|
|
|
|
child_argv[0] = command_line;
|
2017-11-01 07:07:33 +08:00
|
|
|
argv_array_pushf(&child_env, "GIT_DIR=%s", absolute_path(get_git_dir()));
|
2018-07-15 02:38:59 +08:00
|
|
|
argv_array_pushf(&child_env, "GIT_WORK_TREE=%s",
|
|
|
|
|
absolute_path(get_git_work_tree()));
|
2017-11-01 07:07:33 +08:00
|
|
|
status = run_command_v_opt_cd_env(child_argv, RUN_USING_SHELL, NULL,
|
|
|
|
|
child_env.argv);
|
2017-01-02 23:26:47 +08:00
|
|
|
|
|
|
|
|
/* force re-reading of the cache */
|
2019-01-12 10:13:26 +08:00
|
|
|
if (discard_index(r->index) < 0 || repo_read_index(r) < 0)
|
2017-01-02 23:26:47 +08:00
|
|
|
return error(_("could not read index"));
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
dirty = require_clean_work_tree(r, "rebase", NULL, 1, 1);
|
2017-01-02 23:26:47 +08:00
|
|
|
|
|
|
|
|
if (status) {
|
|
|
|
|
warning(_("execution failed: %s\n%s"
|
|
|
|
|
"You can fix the problem, and then run\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git rebase --continue\n"
|
|
|
|
|
"\n"),
|
|
|
|
|
command_line,
|
|
|
|
|
dirty ? N_("and made changes to the index and/or the "
|
|
|
|
|
"working tree\n") : "");
|
|
|
|
|
if (status == 127)
|
|
|
|
|
/* command not found */
|
|
|
|
|
status = 1;
|
|
|
|
|
} else if (dirty) {
|
|
|
|
|
warning(_("execution succeeded: %s\nbut "
|
|
|
|
|
"left changes to the index and/or the working tree\n"
|
|
|
|
|
"Commit or stash your changes, and then run\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git rebase --continue\n"
|
|
|
|
|
"\n"), command_line);
|
|
|
|
|
status = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-01 07:07:33 +08:00
|
|
|
argv_array_clear(&child_env);
|
|
|
|
|
|
2017-01-02 23:26:47 +08:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
static int safe_append(const char *filename, const char *fmt, ...)
|
|
|
|
|
{
|
|
|
|
|
va_list ap;
|
|
|
|
|
struct lock_file lock = LOCK_INIT;
|
|
|
|
|
int fd = hold_lock_file_for_update(&lock, filename,
|
|
|
|
|
LOCK_REPORT_ON_ERROR);
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
if (fd < 0)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
if (strbuf_read_file(&buf, filename, 0) < 0 && errno != ENOENT) {
|
|
|
|
|
error_errno(_("could not read '%s'"), filename);
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
strbuf_complete(&buf, '\n');
|
|
|
|
|
va_start(ap, fmt);
|
|
|
|
|
strbuf_vaddf(&buf, fmt, ap);
|
|
|
|
|
va_end(ap);
|
|
|
|
|
|
|
|
|
|
if (write_in_full(fd, buf.buf, buf.len) < 0) {
|
|
|
|
|
error_errno(_("could not write to '%s'"), filename);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
if (commit_lock_file(&lock) < 0) {
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
return error(_("failed to finalize '%s'"), filename);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_label(struct repository *r, const char *name, int len)
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
{
|
2018-11-10 13:48:56 +08:00
|
|
|
struct ref_store *refs = get_main_ref_store(r);
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
struct ref_transaction *transaction;
|
|
|
|
|
struct strbuf ref_name = STRBUF_INIT, err = STRBUF_INIT;
|
|
|
|
|
struct strbuf msg = STRBUF_INIT;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
struct object_id head_oid;
|
|
|
|
|
|
|
|
|
|
if (len == 1 && *name == '#')
|
2018-07-21 15:49:38 +08:00
|
|
|
return error(_("illegal label name: '%.*s'"), len, name);
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
|
|
|
|
|
strbuf_addf(&ref_name, "refs/rewritten/%.*s", len, name);
|
|
|
|
|
strbuf_addf(&msg, "rebase -i (label) '%.*s'", len, name);
|
|
|
|
|
|
|
|
|
|
transaction = ref_store_transaction_begin(refs, &err);
|
|
|
|
|
if (!transaction) {
|
|
|
|
|
error("%s", err.buf);
|
|
|
|
|
ret = -1;
|
|
|
|
|
} else if (get_oid("HEAD", &head_oid)) {
|
|
|
|
|
error(_("could not read HEAD"));
|
|
|
|
|
ret = -1;
|
|
|
|
|
} else if (ref_transaction_update(transaction, ref_name.buf, &head_oid,
|
|
|
|
|
NULL, 0, msg.buf, &err) < 0 ||
|
|
|
|
|
ref_transaction_commit(transaction, &err)) {
|
|
|
|
|
error("%s", err.buf);
|
|
|
|
|
ret = -1;
|
|
|
|
|
}
|
|
|
|
|
ref_transaction_free(transaction);
|
|
|
|
|
strbuf_release(&err);
|
|
|
|
|
strbuf_release(&msg);
|
|
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
|
ret = safe_append(rebase_path_refs_to_delete(),
|
|
|
|
|
"%s\n", ref_name.buf);
|
|
|
|
|
strbuf_release(&ref_name);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *reflog_message(struct replay_opts *opts,
|
|
|
|
|
const char *sub_action, const char *fmt, ...);
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_reset(struct repository *r,
|
|
|
|
|
const char *name, int len,
|
|
|
|
|
struct replay_opts *opts)
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
{
|
|
|
|
|
struct strbuf ref_name = STRBUF_INIT;
|
|
|
|
|
struct object_id oid;
|
|
|
|
|
struct lock_file lock = LOCK_INIT;
|
|
|
|
|
struct tree_desc desc;
|
|
|
|
|
struct tree *tree;
|
|
|
|
|
struct unpack_trees_options unpack_tree_opts;
|
2018-10-30 16:09:37 +08:00
|
|
|
int ret = 0;
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
|
2019-01-12 10:13:24 +08:00
|
|
|
if (repo_hold_locked_index(r, &lock, LOCK_REPORT_ON_ERROR) < 0)
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
return -1;
|
|
|
|
|
|
2018-05-04 07:01:23 +08:00
|
|
|
if (len == 10 && !strncmp("[new root]", name, len)) {
|
|
|
|
|
if (!opts->have_squash_onto) {
|
|
|
|
|
const char *hex;
|
|
|
|
|
if (commit_tree("", 0, the_hash_algo->empty_tree,
|
|
|
|
|
NULL, &opts->squash_onto,
|
|
|
|
|
NULL, NULL))
|
|
|
|
|
return error(_("writing fake root commit"));
|
|
|
|
|
opts->have_squash_onto = 1;
|
|
|
|
|
hex = oid_to_hex(&opts->squash_onto);
|
|
|
|
|
if (write_message(hex, strlen(hex),
|
|
|
|
|
rebase_path_squash_onto(), 0))
|
|
|
|
|
return error(_("writing squash-onto"));
|
|
|
|
|
}
|
|
|
|
|
oidcpy(&oid, &opts->squash_onto);
|
|
|
|
|
} else {
|
2018-10-30 16:09:37 +08:00
|
|
|
int i;
|
|
|
|
|
|
2018-05-04 07:01:23 +08:00
|
|
|
/* Determine the length of the label */
|
|
|
|
|
for (i = 0; i < len; i++)
|
|
|
|
|
if (isspace(name[i]))
|
2018-10-30 16:09:37 +08:00
|
|
|
break;
|
|
|
|
|
len = i;
|
2018-05-04 07:01:23 +08:00
|
|
|
|
|
|
|
|
strbuf_addf(&ref_name, "refs/rewritten/%.*s", len, name);
|
|
|
|
|
if (get_oid(ref_name.buf, &oid) &&
|
|
|
|
|
get_oid(ref_name.buf + strlen("refs/rewritten/"), &oid)) {
|
|
|
|
|
error(_("could not read '%s'"), ref_name.buf);
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
strbuf_release(&ref_name);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
memset(&unpack_tree_opts, 0, sizeof(unpack_tree_opts));
|
|
|
|
|
setup_unpack_trees_porcelain(&unpack_tree_opts, "reset");
|
|
|
|
|
unpack_tree_opts.head_idx = 1;
|
2018-11-10 13:48:56 +08:00
|
|
|
unpack_tree_opts.src_index = r->index;
|
|
|
|
|
unpack_tree_opts.dst_index = r->index;
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
unpack_tree_opts.fn = oneway_merge;
|
|
|
|
|
unpack_tree_opts.merge = 1;
|
|
|
|
|
unpack_tree_opts.update = 1;
|
|
|
|
|
|
2019-01-12 10:13:26 +08:00
|
|
|
if (repo_read_index_unmerged(r)) {
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
strbuf_release(&ref_name);
|
|
|
|
|
return error_resolve_conflict(_(action_name(opts)));
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-27 17:28:48 +08:00
|
|
|
if (!fill_tree_descriptor(r, &desc, &oid)) {
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
error(_("failed to find tree of %s"), oid_to_hex(&oid));
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
free((void *)desc.buffer);
|
|
|
|
|
strbuf_release(&ref_name);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (unpack_trees(1, &desc, &unpack_tree_opts)) {
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
free((void *)desc.buffer);
|
|
|
|
|
strbuf_release(&ref_name);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tree = parse_tree_indirect(&oid);
|
2018-11-10 13:49:02 +08:00
|
|
|
prime_cache_tree(r, r->index, tree);
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (write_locked_index(r->index, &lock, COMMIT_LOCK) < 0)
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
ret = error(_("could not write index"));
|
|
|
|
|
free((void *)desc.buffer);
|
|
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
|
ret = update_ref(reflog_message(opts, "reset", "'%.*s'",
|
|
|
|
|
len, name), "HEAD", &oid,
|
|
|
|
|
NULL, 0, UPDATE_REFS_MSG_ON_ERR);
|
|
|
|
|
|
|
|
|
|
strbuf_release(&ref_name);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-21 22:52:45 +08:00
|
|
|
static struct commit *lookup_label(const char *label, int len,
|
|
|
|
|
struct strbuf *buf)
|
|
|
|
|
{
|
|
|
|
|
struct commit *commit;
|
|
|
|
|
|
|
|
|
|
strbuf_reset(buf);
|
|
|
|
|
strbuf_addf(buf, "refs/rewritten/%.*s", len, label);
|
|
|
|
|
commit = lookup_commit_reference_by_name(buf->buf);
|
|
|
|
|
if (!commit) {
|
|
|
|
|
/* fall back to non-rewritten ref or commit */
|
|
|
|
|
strbuf_splice(buf, 0, strlen("refs/rewritten/"), "", 0);
|
|
|
|
|
commit = lookup_commit_reference_by_name(buf->buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!commit)
|
|
|
|
|
error(_("could not resolve '%s'"), buf->buf);
|
|
|
|
|
|
|
|
|
|
return commit;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_merge(struct repository *r,
|
|
|
|
|
struct commit *commit,
|
|
|
|
|
const char *arg, int arg_len,
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
int flags, struct replay_opts *opts)
|
|
|
|
|
{
|
|
|
|
|
int run_commit_flags = (flags & TODO_EDIT_MERGE_MSG) ?
|
|
|
|
|
EDIT_MSG | VERIFY_MSG : 0;
|
|
|
|
|
struct strbuf ref_name = STRBUF_INIT;
|
|
|
|
|
struct commit *head_commit, *merge_commit, *i;
|
|
|
|
|
struct commit_list *bases, *j, *reversed = NULL;
|
2017-12-21 22:52:45 +08:00
|
|
|
struct commit_list *to_merge = NULL, **tail = &to_merge;
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
struct merge_options o;
|
2017-12-21 22:52:45 +08:00
|
|
|
int merge_arg_len, oneline_offset, can_fast_forward, ret, k;
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
static struct lock_file lock;
|
|
|
|
|
const char *p;
|
|
|
|
|
|
2019-01-12 10:13:24 +08:00
|
|
|
if (repo_hold_locked_index(r, &lock, LOCK_REPORT_ON_ERROR) < 0) {
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
ret = -1;
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
head_commit = lookup_commit_reference_by_name("HEAD");
|
|
|
|
|
if (!head_commit) {
|
|
|
|
|
ret = error(_("cannot merge without a current revision"));
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-21 22:52:45 +08:00
|
|
|
/*
|
|
|
|
|
* For octopus merges, the arg starts with the list of revisions to be
|
|
|
|
|
* merged. The list is optionally followed by '#' and the oneline.
|
|
|
|
|
*/
|
|
|
|
|
merge_arg_len = oneline_offset = arg_len;
|
|
|
|
|
for (p = arg; p - arg < arg_len; p += strspn(p, " \t\n")) {
|
|
|
|
|
if (!*p)
|
|
|
|
|
break;
|
|
|
|
|
if (*p == '#' && (!p[1] || isspace(p[1]))) {
|
|
|
|
|
p += 1 + strspn(p + 1, " \t\n");
|
|
|
|
|
oneline_offset = p - arg;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
k = strcspn(p, " \t\n");
|
|
|
|
|
if (!k)
|
|
|
|
|
continue;
|
|
|
|
|
merge_commit = lookup_label(p, k, &ref_name);
|
|
|
|
|
if (!merge_commit) {
|
|
|
|
|
ret = error(_("unable to parse '%.*s'"), k, p);
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
tail = &commit_list_insert(merge_commit, tail)->next;
|
|
|
|
|
p += k;
|
|
|
|
|
merge_arg_len = p - arg;
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
}
|
|
|
|
|
|
2017-12-21 22:52:45 +08:00
|
|
|
if (!to_merge) {
|
|
|
|
|
ret = error(_("nothing to merge: '%.*s'"), arg_len, arg);
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-04 07:01:28 +08:00
|
|
|
if (opts->have_squash_onto &&
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
oideq(&head_commit->object.oid, &opts->squash_onto)) {
|
2018-05-04 07:01:28 +08:00
|
|
|
/*
|
|
|
|
|
* When the user tells us to "merge" something into a
|
|
|
|
|
* "[new root]", let's simply fast-forward to the merge head.
|
|
|
|
|
*/
|
|
|
|
|
rollback_lock_file(&lock);
|
2017-12-21 22:52:45 +08:00
|
|
|
if (to_merge->next)
|
|
|
|
|
ret = error(_("octopus merge cannot be executed on "
|
|
|
|
|
"top of a [new root]"));
|
|
|
|
|
else
|
2018-11-10 13:48:56 +08:00
|
|
|
ret = fast_forward_to(r, &to_merge->item->object.oid,
|
2017-12-21 22:52:45 +08:00
|
|
|
&head_commit->object.oid, 0,
|
|
|
|
|
opts);
|
2018-05-04 07:01:28 +08:00
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
if (commit) {
|
|
|
|
|
const char *message = get_commit_buffer(commit, NULL);
|
|
|
|
|
const char *body;
|
|
|
|
|
int len;
|
|
|
|
|
|
|
|
|
|
if (!message) {
|
|
|
|
|
ret = error(_("could not get commit message of '%s'"),
|
|
|
|
|
oid_to_hex(&commit->object.oid));
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
write_author_script(message);
|
|
|
|
|
find_commit_subject(message, &body);
|
|
|
|
|
len = strlen(body);
|
2018-11-10 13:48:56 +08:00
|
|
|
ret = write_message(body, len, git_path_merge_msg(r), 0);
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
unuse_commit_buffer(commit, message);
|
|
|
|
|
if (ret) {
|
|
|
|
|
error_errno(_("could not write '%s'"),
|
2018-11-10 13:48:56 +08:00
|
|
|
git_path_merge_msg(r));
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
int len;
|
|
|
|
|
|
|
|
|
|
strbuf_addf(&buf, "author %s", git_author_info(0));
|
|
|
|
|
write_author_script(buf.buf);
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
|
|
|
|
|
if (oneline_offset < arg_len) {
|
|
|
|
|
p = arg + oneline_offset;
|
|
|
|
|
len = arg_len - oneline_offset;
|
|
|
|
|
} else {
|
2017-12-21 22:52:45 +08:00
|
|
|
strbuf_addf(&buf, "Merge %s '%.*s'",
|
|
|
|
|
to_merge->next ? "branches" : "branch",
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
merge_arg_len, arg);
|
|
|
|
|
p = buf.buf;
|
|
|
|
|
len = buf.len;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
ret = write_message(p, len, git_path_merge_msg(r), 0);
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
strbuf_release(&buf);
|
|
|
|
|
if (ret) {
|
|
|
|
|
error_errno(_("could not write '%s'"),
|
2018-11-10 13:48:56 +08:00
|
|
|
git_path_merge_msg(r));
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-25 20:28:56 +08:00
|
|
|
/*
|
|
|
|
|
* If HEAD is not identical to the first parent of the original merge
|
|
|
|
|
* commit, we cannot fast-forward.
|
|
|
|
|
*/
|
|
|
|
|
can_fast_forward = opts->allow_ff && commit && commit->parents &&
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
oideq(&commit->parents->item->object.oid,
|
|
|
|
|
&head_commit->object.oid);
|
2018-04-25 20:28:56 +08:00
|
|
|
|
|
|
|
|
/*
|
2017-12-21 22:52:45 +08:00
|
|
|
* If any merge head is different from the original one, we cannot
|
2018-04-25 20:28:56 +08:00
|
|
|
* fast-forward.
|
|
|
|
|
*/
|
|
|
|
|
if (can_fast_forward) {
|
2017-12-21 22:52:45 +08:00
|
|
|
struct commit_list *p = commit->parents->next;
|
2018-04-25 20:28:56 +08:00
|
|
|
|
2017-12-21 22:52:45 +08:00
|
|
|
for (j = to_merge; j && p; j = j->next, p = p->next)
|
2018-08-29 05:22:48 +08:00
|
|
|
if (!oideq(&j->item->object.oid,
|
2017-12-21 22:52:45 +08:00
|
|
|
&p->item->object.oid)) {
|
|
|
|
|
can_fast_forward = 0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* If the number of merge heads differs from the original merge
|
|
|
|
|
* commit, we cannot fast-forward.
|
|
|
|
|
*/
|
|
|
|
|
if (j || p)
|
2018-04-25 20:28:56 +08:00
|
|
|
can_fast_forward = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-21 22:52:45 +08:00
|
|
|
if (can_fast_forward) {
|
2018-04-25 20:28:56 +08:00
|
|
|
rollback_lock_file(&lock);
|
2018-11-10 13:48:56 +08:00
|
|
|
ret = fast_forward_to(r, &commit->object.oid,
|
2018-04-25 20:28:56 +08:00
|
|
|
&head_commit->object.oid, 0, opts);
|
2019-05-02 18:22:49 +08:00
|
|
|
if (flags & TODO_EDIT_MERGE_MSG) {
|
|
|
|
|
run_commit_flags |= AMEND_MSG;
|
|
|
|
|
goto fast_forward_edit;
|
|
|
|
|
}
|
2018-04-25 20:28:56 +08:00
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-21 22:52:45 +08:00
|
|
|
if (to_merge->next) {
|
|
|
|
|
/* Octopus merge */
|
|
|
|
|
struct child_process cmd = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
|
|
if (read_env_script(&cmd.env_array)) {
|
|
|
|
|
const char *gpg_opt = gpg_sign_opt_quoted(opts);
|
|
|
|
|
|
|
|
|
|
ret = error(_(staged_changes_advice), gpg_opt, gpg_opt);
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cmd.git_cmd = 1;
|
|
|
|
|
argv_array_push(&cmd.args, "merge");
|
|
|
|
|
argv_array_push(&cmd.args, "-s");
|
|
|
|
|
argv_array_push(&cmd.args, "octopus");
|
|
|
|
|
argv_array_push(&cmd.args, "--no-edit");
|
|
|
|
|
argv_array_push(&cmd.args, "--no-ff");
|
|
|
|
|
argv_array_push(&cmd.args, "--no-log");
|
|
|
|
|
argv_array_push(&cmd.args, "--no-stat");
|
|
|
|
|
argv_array_push(&cmd.args, "-F");
|
2018-11-10 13:48:56 +08:00
|
|
|
argv_array_push(&cmd.args, git_path_merge_msg(r));
|
2017-12-21 22:52:45 +08:00
|
|
|
if (opts->gpg_sign)
|
|
|
|
|
argv_array_push(&cmd.args, opts->gpg_sign);
|
|
|
|
|
|
|
|
|
|
/* Add the tips to be merged */
|
|
|
|
|
for (j = to_merge; j; j = j->next)
|
|
|
|
|
argv_array_push(&cmd.args,
|
|
|
|
|
oid_to_hex(&j->item->object.oid));
|
|
|
|
|
|
|
|
|
|
strbuf_release(&ref_name);
|
2018-11-10 13:48:56 +08:00
|
|
|
unlink(git_path_cherry_pick_head(r));
|
2017-12-21 22:52:45 +08:00
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
ret = run_command(&cmd);
|
|
|
|
|
|
|
|
|
|
/* force re-reading of the cache */
|
2018-11-10 13:48:56 +08:00
|
|
|
if (!ret && (discard_index(r->index) < 0 ||
|
2019-01-12 10:13:26 +08:00
|
|
|
repo_read_index(r) < 0))
|
2017-12-21 22:52:45 +08:00
|
|
|
ret = error(_("could not read index"));
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
merge_commit = to_merge->item;
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
bases = get_merge_bases(head_commit, merge_commit);
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
if (bases && oideq(&merge_commit->object.oid,
|
|
|
|
|
&bases->item->object.oid)) {
|
2018-04-25 20:29:31 +08:00
|
|
|
ret = 0;
|
|
|
|
|
/* skip merging an ancestor of HEAD */
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-13 07:25:58 +08:00
|
|
|
write_message(oid_to_hex(&merge_commit->object.oid), GIT_SHA1_HEXSZ,
|
2019-01-05 05:33:33 +08:00
|
|
|
git_path_merge_head(r), 0);
|
|
|
|
|
write_message("no-ff", 5, git_path_merge_mode(r), 0);
|
2018-11-13 07:25:58 +08:00
|
|
|
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
for (j = bases; j; j = j->next)
|
|
|
|
|
commit_list_insert(j->item, &reversed);
|
|
|
|
|
free_commit_list(bases);
|
|
|
|
|
|
2019-01-12 10:13:26 +08:00
|
|
|
repo_read_index(r);
|
2019-01-12 10:13:29 +08:00
|
|
|
init_merge_options(&o, r);
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
o.branch1 = "HEAD";
|
|
|
|
|
o.branch2 = ref_name.buf;
|
|
|
|
|
o.buffer_output = 2;
|
|
|
|
|
|
|
|
|
|
ret = merge_recursive(&o, head_commit, merge_commit, reversed, &i);
|
|
|
|
|
if (ret <= 0)
|
|
|
|
|
fputs(o.obuf.buf, stdout);
|
|
|
|
|
strbuf_release(&o.obuf);
|
|
|
|
|
if (ret < 0) {
|
|
|
|
|
error(_("could not even attempt to merge '%.*s'"),
|
|
|
|
|
merge_arg_len, arg);
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* The return value of merge_recursive() is 1 on clean, and 0 on
|
|
|
|
|
* unclean merge.
|
|
|
|
|
*
|
|
|
|
|
* Let's reverse that, so that do_merge() returns 0 upon success and
|
|
|
|
|
* 1 upon failed merge (keeping the return value -1 for the cases where
|
|
|
|
|
* we will want to reschedule the `merge` command).
|
|
|
|
|
*/
|
|
|
|
|
ret = !ret;
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (r->index->cache_changed &&
|
|
|
|
|
write_locked_index(r->index, &lock, COMMIT_LOCK)) {
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
ret = error(_("merge: Unable to write new index file"));
|
|
|
|
|
goto leave_merge;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
if (ret)
|
2018-11-10 13:48:56 +08:00
|
|
|
repo_rerere(r, opts->allow_rerere_auto);
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
else
|
|
|
|
|
/*
|
|
|
|
|
* In case of problems, we now want to return a positive
|
|
|
|
|
* value (a negative one would indicate that the `merge`
|
|
|
|
|
* command needs to be rescheduled).
|
|
|
|
|
*/
|
2019-05-02 18:22:49 +08:00
|
|
|
fast_forward_edit:
|
2018-11-10 13:48:56 +08:00
|
|
|
ret = !!run_git_commit(r, git_path_merge_msg(r), opts,
|
|
|
|
|
run_commit_flags);
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
|
|
|
|
|
leave_merge:
|
|
|
|
|
strbuf_release(&ref_name);
|
|
|
|
|
rollback_lock_file(&lock);
|
2017-12-21 22:52:45 +08:00
|
|
|
free_commit_list(to_merge);
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
static int is_final_fixup(struct todo_list *todo_list)
|
|
|
|
|
{
|
|
|
|
|
int i = todo_list->current;
|
|
|
|
|
|
|
|
|
|
if (!is_fixup(todo_list->items[i].command))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
while (++i < todo_list->nr)
|
|
|
|
|
if (is_fixup(todo_list->items[i].command))
|
|
|
|
|
return 0;
|
|
|
|
|
else if (!is_noop(todo_list->items[i].command))
|
|
|
|
|
break;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:28:16 +08:00
|
|
|
static enum todo_command peek_command(struct todo_list *todo_list, int offset)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = todo_list->current + offset; i < todo_list->nr; i++)
|
|
|
|
|
if (!is_noop(todo_list->items[i].command))
|
|
|
|
|
return todo_list->items[i].command;
|
|
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:28:27 +08:00
|
|
|
static int apply_autostash(struct replay_opts *opts)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf stash_sha1 = STRBUF_INIT;
|
|
|
|
|
struct child_process child = CHILD_PROCESS_INIT;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
if (!read_oneliner(&stash_sha1, rebase_path_autostash(), 1)) {
|
|
|
|
|
strbuf_release(&stash_sha1);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
strbuf_trim(&stash_sha1);
|
|
|
|
|
|
|
|
|
|
child.git_cmd = 1;
|
2017-05-18 18:02:33 +08:00
|
|
|
child.no_stdout = 1;
|
|
|
|
|
child.no_stderr = 1;
|
2017-01-02 23:28:27 +08:00
|
|
|
argv_array_push(&child.args, "stash");
|
|
|
|
|
argv_array_push(&child.args, "apply");
|
|
|
|
|
argv_array_push(&child.args, stash_sha1.buf);
|
|
|
|
|
if (!run_command(&child))
|
2017-06-20 01:56:02 +08:00
|
|
|
fprintf(stderr, _("Applied autostash.\n"));
|
2017-01-02 23:28:27 +08:00
|
|
|
else {
|
|
|
|
|
struct child_process store = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
|
|
store.git_cmd = 1;
|
|
|
|
|
argv_array_push(&store.args, "stash");
|
|
|
|
|
argv_array_push(&store.args, "store");
|
|
|
|
|
argv_array_push(&store.args, "-m");
|
|
|
|
|
argv_array_push(&store.args, "autostash");
|
|
|
|
|
argv_array_push(&store.args, "-q");
|
|
|
|
|
argv_array_push(&store.args, stash_sha1.buf);
|
|
|
|
|
if (run_command(&store))
|
|
|
|
|
ret = error(_("cannot store %s"), stash_sha1.buf);
|
|
|
|
|
else
|
2017-06-20 01:56:02 +08:00
|
|
|
fprintf(stderr,
|
|
|
|
|
_("Applying autostash resulted in conflicts.\n"
|
|
|
|
|
"Your changes are safe in the stash.\n"
|
|
|
|
|
"You can run \"git stash pop\" or"
|
|
|
|
|
" \"git stash drop\" at any time.\n"));
|
2017-01-02 23:28:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
strbuf_release(&stash_sha1);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:28:09 +08:00
|
|
|
static const char *reflog_message(struct replay_opts *opts,
|
|
|
|
|
const char *sub_action, const char *fmt, ...)
|
|
|
|
|
{
|
|
|
|
|
va_list ap;
|
|
|
|
|
static struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
va_start(ap, fmt);
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
strbuf_addstr(&buf, action_name(opts));
|
|
|
|
|
if (sub_action)
|
|
|
|
|
strbuf_addf(&buf, " (%s)", sub_action);
|
|
|
|
|
if (fmt) {
|
|
|
|
|
strbuf_addstr(&buf, ": ");
|
|
|
|
|
strbuf_vaddf(&buf, fmt, ap);
|
|
|
|
|
}
|
|
|
|
|
va_end(ap);
|
|
|
|
|
|
|
|
|
|
return buf.buf;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-20 03:03:07 +08:00
|
|
|
static int run_git_checkout(struct repository *r, struct replay_opts *opts,
|
|
|
|
|
const char *commit, const char *action)
|
2018-08-11 00:51:33 +08:00
|
|
|
{
|
|
|
|
|
struct child_process cmd = CHILD_PROCESS_INIT;
|
2019-03-20 03:03:07 +08:00
|
|
|
int ret;
|
2018-08-11 00:51:33 +08:00
|
|
|
|
|
|
|
|
cmd.git_cmd = 1;
|
|
|
|
|
|
|
|
|
|
argv_array_push(&cmd.args, "checkout");
|
|
|
|
|
argv_array_push(&cmd.args, commit);
|
|
|
|
|
argv_array_pushf(&cmd.env_array, GIT_REFLOG_ACTION "=%s", action);
|
|
|
|
|
|
|
|
|
|
if (opts->verbose)
|
2019-03-20 03:03:07 +08:00
|
|
|
ret = run_command(&cmd);
|
2018-08-11 00:51:33 +08:00
|
|
|
else
|
2019-03-20 03:03:07 +08:00
|
|
|
ret = run_command_silent_on_success(&cmd);
|
|
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
|
discard_index(r->index);
|
|
|
|
|
|
|
|
|
|
return ret;
|
2018-08-11 00:51:33 +08:00
|
|
|
}
|
|
|
|
|
|
2019-03-20 03:03:07 +08:00
|
|
|
int prepare_branch_to_be_rebased(struct repository *r, struct replay_opts *opts,
|
|
|
|
|
const char *commit)
|
2018-08-11 00:51:33 +08:00
|
|
|
{
|
|
|
|
|
const char *action;
|
|
|
|
|
|
|
|
|
|
if (commit && *commit) {
|
|
|
|
|
action = reflog_message(opts, "start", "checkout %s", commit);
|
2019-03-20 03:03:07 +08:00
|
|
|
if (run_git_checkout(r, opts, commit, action))
|
2018-08-11 00:51:33 +08:00
|
|
|
return error(_("could not checkout %s"), commit);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-20 03:03:07 +08:00
|
|
|
static int checkout_onto(struct repository *r, struct replay_opts *opts,
|
2019-04-17 22:30:39 +08:00
|
|
|
const char *onto_name, const struct object_id *onto,
|
2018-08-28 20:10:37 +08:00
|
|
|
const char *orig_head)
|
2018-08-11 00:51:34 +08:00
|
|
|
{
|
|
|
|
|
struct object_id oid;
|
|
|
|
|
const char *action = reflog_message(opts, "start", "checkout %s", onto_name);
|
|
|
|
|
|
|
|
|
|
if (get_oid(orig_head, &oid))
|
|
|
|
|
return error(_("%s: not a valid OID"), orig_head);
|
|
|
|
|
|
2019-04-17 22:30:39 +08:00
|
|
|
if (run_git_checkout(r, opts, oid_to_hex(onto), action)) {
|
2018-08-11 00:51:34 +08:00
|
|
|
apply_autostash(opts);
|
|
|
|
|
sequencer_remove_state(opts);
|
|
|
|
|
return error(_("could not detach HEAD"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return update_ref(NULL, "ORIG_HEAD", &oid, NULL, 0, UPDATE_REFS_MSG_ON_ERR);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int stopped_at_head(struct repository *r)
|
2018-10-12 21:14:26 +08:00
|
|
|
{
|
|
|
|
|
struct object_id head;
|
|
|
|
|
struct commit *commit;
|
|
|
|
|
struct commit_message message;
|
|
|
|
|
|
2018-11-02 10:04:58 +08:00
|
|
|
if (get_oid("HEAD", &head) ||
|
2018-11-10 13:48:57 +08:00
|
|
|
!(commit = lookup_commit(r, &head)) ||
|
2018-10-12 21:14:26 +08:00
|
|
|
parse_commit(commit) || get_message(commit, &message))
|
|
|
|
|
fprintf(stderr, _("Stopped at HEAD\n"));
|
|
|
|
|
else {
|
|
|
|
|
fprintf(stderr, _("Stopped at %s\n"), message.label);
|
|
|
|
|
free_message(commit, &message);
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-25 20:28:33 +08:00
|
|
|
static const char rescheduled_advice[] =
|
|
|
|
|
N_("Could not execute the todo command\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" %.*s"
|
|
|
|
|
"\n"
|
|
|
|
|
"It has been rescheduled; To edit the command before continuing, please\n"
|
|
|
|
|
"edit the todo list first:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git rebase --edit-todo\n"
|
|
|
|
|
" git rebase --continue\n");
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int pick_commits(struct repository *r,
|
|
|
|
|
struct todo_list *todo_list,
|
|
|
|
|
struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
int res = 0, reschedule = 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
|
|
|
|
setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
|
|
|
|
|
if (opts->allow_ff)
|
|
|
|
|
assert(!(opts->signoff || opts->no_commit ||
|
|
|
|
|
opts->record_origin || opts->edit));
|
2018-11-10 13:48:56 +08:00
|
|
|
if (read_and_refresh_cache(r, opts))
|
2016-09-09 22:37:21 +08:00
|
|
|
return -1;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
while (todo_list->current < todo_list->nr) {
|
|
|
|
|
struct todo_item *item = todo_list->items + todo_list->current;
|
2019-01-29 23:01:46 +08:00
|
|
|
const char *arg = todo_item_get_arg(todo_list, item);
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
if (save_todo(todo_list, opts))
|
2016-09-09 22:37:50 +08:00
|
|
|
return -1;
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
if (is_rebase_i(opts)) {
|
2017-01-02 23:36:20 +08:00
|
|
|
if (item->command != TODO_COMMENT) {
|
|
|
|
|
FILE *f = fopen(rebase_path_msgnum(), "w");
|
|
|
|
|
|
|
|
|
|
todo_list->done_nr++;
|
|
|
|
|
|
|
|
|
|
if (f) {
|
|
|
|
|
fprintf(f, "%d\n", todo_list->done_nr);
|
|
|
|
|
fclose(f);
|
|
|
|
|
}
|
git-rebase, sequencer: extend --quiet option for the interactive machinery
While 'quiet' and 'interactive' may sound like antonyms, the interactive
machinery actually has logic that implements several
interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
which won't pop up an editor. The rewrite of interactive rebase in C
added a quiet option, though it only turns stats off. Since we want to
make the interactive machinery also take over for git-rebase--merge, it
should fully implement the --quiet option.
git-rebase--interactive was already somewhat quieter than
git-rebase--merge and git-rebase--am, possibly because cherry-pick has
just traditionally been quieter. As such, we only drop a few
informational messages -- "Rebasing (n/m)" and "Successfully rebased..."
Also, for simplicity, remove the differences in how quiet and verbose
options were recorded. Having one be signalled by the presence of a
"verbose" file in the state_dir, while the other was signalled by the
contents of a "quiet" file was just weirdly inconsistent. (This
inconsistency pre-dated the rewrite into C.) Make them consistent by
having them both key off the presence of the file.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:36 +08:00
|
|
|
if (!opts->quiet)
|
|
|
|
|
fprintf(stderr, "Rebasing (%d/%d)%s",
|
|
|
|
|
todo_list->done_nr,
|
|
|
|
|
todo_list->total_nr,
|
|
|
|
|
opts->verbose ? "\n" : "\r");
|
2017-01-02 23:36:20 +08:00
|
|
|
}
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
unlink(rebase_path_message());
|
|
|
|
|
unlink(rebase_path_author_script());
|
|
|
|
|
unlink(rebase_path_stopped_sha());
|
|
|
|
|
unlink(rebase_path_amend());
|
2019-06-27 17:28:52 +08:00
|
|
|
unlink(git_path_merge_head(r));
|
2018-02-11 17:43:28 +08:00
|
|
|
delete_ref(NULL, "REBASE_HEAD", NULL, REF_NO_DEREF);
|
2018-10-12 21:14:26 +08:00
|
|
|
|
rebase: fix garbled progress display with '-x'
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: true
Executing: true
Executing: true)
Successfully rebased and updated refs/heads/master.
Note the ')' at the end of the last line. It gets more garbled as the
range of commits increases:
$ git rebase -x true HEAD~50
Executing: true)
[ repeated 3 more times ]
Executing: true0)
[ repeated 44 more times ]
Executing: true00)
Successfully rebased and updated refs/heads/master.
Those extra numbers and ')' are remnants of the previously displayed
"Rebasing (N/M)" progress lines that are usually completely
overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and
the "N/M" part is long.
Make sure that the previously displayed "Rebasing (N/M)" line is
cleared by using the term_clear_line() helper function added in the
previous patch. Do so only when not being '--verbose', because in
that case these "Rebasing (N/M)" lines are not printed as progress
(i.e. as lines with '\r' at the end), but as "regular" output (with
'\n' at the end).
A couple of other rebase commands print similar messages, e.g.
"Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break'
commands, or the "Successfully rebased and updated <full-ref>." at the
very end. These are so long that they practically always overwrite
that "Rebasing (N/M)" progress line, but let's be prudent, and clear
the last line before printing these, too.
In 't3420-rebase-autostash.sh' two helper functions prepare the
expected output of four tests that check the full output of 'git
rebase' and thus are affected by this change, so adjust their
expectations to account for the new line clearing.
Note that this patch doesn't completely eliminate the possibility of
similar garbled outputs, e.g. some error messages from rebase or the
"Auto-merging <file>" message from within the depths of the merge
machinery might not be long enough to completely cover the last
"Rebasing (N/M)" line. This patch doesn't do anything about them,
because dealing with them individually would result in way too much
churn, while having a catch-all term_clear_line() call in the common
code path of pick_commits() would hide the "Rebasing (N/M)" line way
too soon, and it would either flicker or be invisible.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27 21:42:48 +08:00
|
|
|
if (item->command == TODO_BREAK) {
|
|
|
|
|
if (!opts->verbose)
|
|
|
|
|
term_clear_line();
|
2018-11-10 13:48:57 +08:00
|
|
|
return stopped_at_head(r);
|
rebase: fix garbled progress display with '-x'
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: true
Executing: true
Executing: true)
Successfully rebased and updated refs/heads/master.
Note the ')' at the end of the last line. It gets more garbled as the
range of commits increases:
$ git rebase -x true HEAD~50
Executing: true)
[ repeated 3 more times ]
Executing: true0)
[ repeated 44 more times ]
Executing: true00)
Successfully rebased and updated refs/heads/master.
Those extra numbers and ')' are remnants of the previously displayed
"Rebasing (N/M)" progress lines that are usually completely
overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and
the "N/M" part is long.
Make sure that the previously displayed "Rebasing (N/M)" line is
cleared by using the term_clear_line() helper function added in the
previous patch. Do so only when not being '--verbose', because in
that case these "Rebasing (N/M)" lines are not printed as progress
(i.e. as lines with '\r' at the end), but as "regular" output (with
'\n' at the end).
A couple of other rebase commands print similar messages, e.g.
"Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break'
commands, or the "Successfully rebased and updated <full-ref>." at the
very end. These are so long that they practically always overwrite
that "Rebasing (N/M)" progress line, but let's be prudent, and clear
the last line before printing these, too.
In 't3420-rebase-autostash.sh' two helper functions prepare the
expected output of four tests that check the full output of 'git
rebase' and thus are affected by this change, so adjust their
expectations to account for the new line clearing.
Note that this patch doesn't completely eliminate the possibility of
similar garbled outputs, e.g. some error messages from rebase or the
"Auto-merging <file>" message from within the depths of the merge
machinery might not be long enough to completely cover the last
"Rebasing (N/M)" line. This patch doesn't do anything about them,
because dealing with them individually would result in way too much
churn, while having a catch-all term_clear_line() call in the common
code path of pick_commits() would hide the "Rebasing (N/M)" line way
too soon, and it would either flicker or be invisible.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27 21:42:48 +08:00
|
|
|
}
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
}
|
|
|
|
|
if (item->command <= TODO_SQUASH) {
|
2017-01-02 23:28:13 +08:00
|
|
|
if (is_rebase_i(opts))
|
|
|
|
|
setenv("GIT_REFLOG_ACTION", reflog_message(opts,
|
|
|
|
|
command_to_string(item->command), NULL),
|
|
|
|
|
1);
|
2018-11-10 13:48:56 +08:00
|
|
|
res = do_pick_commit(r, item->command, item->commit,
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
opts, is_final_fixup(todo_list));
|
2017-01-02 23:28:34 +08:00
|
|
|
if (is_rebase_i(opts) && res < 0) {
|
|
|
|
|
/* Reschedule */
|
2018-04-25 20:28:33 +08:00
|
|
|
advise(_(rescheduled_advice),
|
|
|
|
|
get_item_line_length(todo_list,
|
|
|
|
|
todo_list->current),
|
|
|
|
|
get_item_line(todo_list,
|
|
|
|
|
todo_list->current));
|
2017-01-02 23:28:34 +08:00
|
|
|
todo_list->current--;
|
|
|
|
|
if (save_todo(todo_list, opts))
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
2017-01-02 23:26:43 +08:00
|
|
|
if (item->command == TODO_EDIT) {
|
|
|
|
|
struct commit *commit = item->commit;
|
rebase: fix garbled progress display with '-x'
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: true
Executing: true
Executing: true)
Successfully rebased and updated refs/heads/master.
Note the ')' at the end of the last line. It gets more garbled as the
range of commits increases:
$ git rebase -x true HEAD~50
Executing: true)
[ repeated 3 more times ]
Executing: true0)
[ repeated 44 more times ]
Executing: true00)
Successfully rebased and updated refs/heads/master.
Those extra numbers and ')' are remnants of the previously displayed
"Rebasing (N/M)" progress lines that are usually completely
overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and
the "N/M" part is long.
Make sure that the previously displayed "Rebasing (N/M)" line is
cleared by using the term_clear_line() helper function added in the
previous patch. Do so only when not being '--verbose', because in
that case these "Rebasing (N/M)" lines are not printed as progress
(i.e. as lines with '\r' at the end), but as "regular" output (with
'\n' at the end).
A couple of other rebase commands print similar messages, e.g.
"Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break'
commands, or the "Successfully rebased and updated <full-ref>." at the
very end. These are so long that they practically always overwrite
that "Rebasing (N/M)" progress line, but let's be prudent, and clear
the last line before printing these, too.
In 't3420-rebase-autostash.sh' two helper functions prepare the
expected output of four tests that check the full output of 'git
rebase' and thus are affected by this change, so adjust their
expectations to account for the new line clearing.
Note that this patch doesn't completely eliminate the possibility of
similar garbled outputs, e.g. some error messages from rebase or the
"Auto-merging <file>" message from within the depths of the merge
machinery might not be long enough to completely cover the last
"Rebasing (N/M)" line. This patch doesn't do anything about them,
because dealing with them individually would result in way too much
churn, while having a catch-all term_clear_line() call in the common
code path of pick_commits() would hide the "Rebasing (N/M)" line way
too soon, and it would either flicker or be invisible.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27 21:42:48 +08:00
|
|
|
if (!res) {
|
|
|
|
|
if (!opts->verbose)
|
|
|
|
|
term_clear_line();
|
2017-03-17 08:19:42 +08:00
|
|
|
fprintf(stderr,
|
2017-03-24 01:02:33 +08:00
|
|
|
_("Stopped at %s... %.*s\n"),
|
2017-01-02 23:26:43 +08:00
|
|
|
short_commit_name(commit),
|
2019-01-29 23:01:46 +08:00
|
|
|
item->arg_len, arg);
|
rebase: fix garbled progress display with '-x'
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: true
Executing: true
Executing: true)
Successfully rebased and updated refs/heads/master.
Note the ')' at the end of the last line. It gets more garbled as the
range of commits increases:
$ git rebase -x true HEAD~50
Executing: true)
[ repeated 3 more times ]
Executing: true0)
[ repeated 44 more times ]
Executing: true00)
Successfully rebased and updated refs/heads/master.
Those extra numbers and ')' are remnants of the previously displayed
"Rebasing (N/M)" progress lines that are usually completely
overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and
the "N/M" part is long.
Make sure that the previously displayed "Rebasing (N/M)" line is
cleared by using the term_clear_line() helper function added in the
previous patch. Do so only when not being '--verbose', because in
that case these "Rebasing (N/M)" lines are not printed as progress
(i.e. as lines with '\r' at the end), but as "regular" output (with
'\n' at the end).
A couple of other rebase commands print similar messages, e.g.
"Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break'
commands, or the "Successfully rebased and updated <full-ref>." at the
very end. These are so long that they practically always overwrite
that "Rebasing (N/M)" progress line, but let's be prudent, and clear
the last line before printing these, too.
In 't3420-rebase-autostash.sh' two helper functions prepare the
expected output of four tests that check the full output of 'git
rebase' and thus are affected by this change, so adjust their
expectations to account for the new line clearing.
Note that this patch doesn't completely eliminate the possibility of
similar garbled outputs, e.g. some error messages from rebase or the
"Auto-merging <file>" message from within the depths of the merge
machinery might not be long enough to completely cover the last
"Rebasing (N/M)" line. This patch doesn't do anything about them,
because dealing with them individually would result in way too much
churn, while having a catch-all term_clear_line() call in the common
code path of pick_commits() would hide the "Rebasing (N/M)" line way
too soon, and it would either flicker or be invisible.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27 21:42:48 +08:00
|
|
|
}
|
2018-11-10 13:48:56 +08:00
|
|
|
return error_with_patch(r, commit,
|
2019-01-29 23:01:46 +08:00
|
|
|
arg, item->arg_len, opts, res, !res);
|
2017-01-02 23:26:43 +08:00
|
|
|
}
|
2017-01-02 23:28:16 +08:00
|
|
|
if (is_rebase_i(opts) && !res)
|
|
|
|
|
record_in_rewritten(&item->commit->object.oid,
|
|
|
|
|
peek_command(todo_list, 1));
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
if (res && is_fixup(item->command)) {
|
|
|
|
|
if (res == 1)
|
|
|
|
|
intend_to_amend();
|
2018-11-10 13:48:56 +08:00
|
|
|
return error_failed_squash(r, item->commit, opts,
|
2019-01-29 23:01:46 +08:00
|
|
|
item->arg_len, arg);
|
sequencer: do not squash 'reword' commits when we hit conflicts
Ever since commit 18633e1a22 ("rebase -i: use the rebase--helper builtin",
2017-02-09), when a commit marked as 'reword' in an interactive rebase
has conflicts and fails to apply, when the rebase is resumed that commit
will be squashed into its parent with its commit message taken.
The issue can be understood better by looking at commit 56dc3ab04b
("sequencer (rebase -i): implement the 'edit' command", 2017-01-02), which
introduced error_with_patch() for the edit command. For the edit command,
it needs to stop the rebase whether or not the patch applies cleanly. If
the patch does apply cleanly, then when it resumes it knows it needs to
amend all changes into the previous commit. If it does not apply cleanly,
then the changes should not be amended. Thus, it passes !res (success of
applying the 'edit' commit) to error_with_patch() for the to_amend flag.
The problematic line of code actually came from commit 04efc8b57c
("sequencer (rebase -i): implement the 'reword' command", 2017-01-02).
Note that to get to this point in the code:
* !!res (i.e. patch application failed)
* item->command < TODO_SQUASH
* item->command != TODO_EDIT
* !is_fixup(item->command) [i.e. not squash or fixup]
So that means this can only be a failed patch application that is either a
pick, revert, or reword. We only need to amend HEAD when rewording the
root commit or a commit that has been fast-forwarded, for any of the other
cases we want a new commit, so we should not set the to_amend flag.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Original-patch-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19 20:46:51 +08:00
|
|
|
} else if (res && is_rebase_i(opts) && item->commit) {
|
|
|
|
|
int to_amend = 0;
|
|
|
|
|
struct object_id oid;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we are rewording and have either
|
|
|
|
|
* fast-forwarded already, or are about to
|
|
|
|
|
* create a new root commit, we want to amend,
|
|
|
|
|
* otherwise we do not.
|
|
|
|
|
*/
|
|
|
|
|
if (item->command == TODO_REWORD &&
|
|
|
|
|
!get_oid("HEAD", &oid) &&
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
(oideq(&item->commit->object.oid, &oid) ||
|
sequencer: do not squash 'reword' commits when we hit conflicts
Ever since commit 18633e1a22 ("rebase -i: use the rebase--helper builtin",
2017-02-09), when a commit marked as 'reword' in an interactive rebase
has conflicts and fails to apply, when the rebase is resumed that commit
will be squashed into its parent with its commit message taken.
The issue can be understood better by looking at commit 56dc3ab04b
("sequencer (rebase -i): implement the 'edit' command", 2017-01-02), which
introduced error_with_patch() for the edit command. For the edit command,
it needs to stop the rebase whether or not the patch applies cleanly. If
the patch does apply cleanly, then when it resumes it knows it needs to
amend all changes into the previous commit. If it does not apply cleanly,
then the changes should not be amended. Thus, it passes !res (success of
applying the 'edit' commit) to error_with_patch() for the to_amend flag.
The problematic line of code actually came from commit 04efc8b57c
("sequencer (rebase -i): implement the 'reword' command", 2017-01-02).
Note that to get to this point in the code:
* !!res (i.e. patch application failed)
* item->command < TODO_SQUASH
* item->command != TODO_EDIT
* !is_fixup(item->command) [i.e. not squash or fixup]
So that means this can only be a failed patch application that is either a
pick, revert, or reword. We only need to amend HEAD when rewording the
root commit or a commit that has been fast-forwarded, for any of the other
cases we want a new commit, so we should not set the to_amend flag.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Original-patch-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19 20:46:51 +08:00
|
|
|
(opts->have_squash_onto &&
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
oideq(&opts->squash_onto, &oid))))
|
sequencer: do not squash 'reword' commits when we hit conflicts
Ever since commit 18633e1a22 ("rebase -i: use the rebase--helper builtin",
2017-02-09), when a commit marked as 'reword' in an interactive rebase
has conflicts and fails to apply, when the rebase is resumed that commit
will be squashed into its parent with its commit message taken.
The issue can be understood better by looking at commit 56dc3ab04b
("sequencer (rebase -i): implement the 'edit' command", 2017-01-02), which
introduced error_with_patch() for the edit command. For the edit command,
it needs to stop the rebase whether or not the patch applies cleanly. If
the patch does apply cleanly, then when it resumes it knows it needs to
amend all changes into the previous commit. If it does not apply cleanly,
then the changes should not be amended. Thus, it passes !res (success of
applying the 'edit' commit) to error_with_patch() for the to_amend flag.
The problematic line of code actually came from commit 04efc8b57c
("sequencer (rebase -i): implement the 'reword' command", 2017-01-02).
Note that to get to this point in the code:
* !!res (i.e. patch application failed)
* item->command < TODO_SQUASH
* item->command != TODO_EDIT
* !is_fixup(item->command) [i.e. not squash or fixup]
So that means this can only be a failed patch application that is either a
pick, revert, or reword. We only need to amend HEAD when rewording the
root commit or a commit that has been fast-forwarded, for any of the other
cases we want a new commit, so we should not set the to_amend flag.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Original-patch-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19 20:46:51 +08:00
|
|
|
to_amend = 1;
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
return res | error_with_patch(r, item->commit,
|
2019-01-29 23:01:46 +08:00
|
|
|
arg, item->arg_len, opts,
|
sequencer: do not squash 'reword' commits when we hit conflicts
Ever since commit 18633e1a22 ("rebase -i: use the rebase--helper builtin",
2017-02-09), when a commit marked as 'reword' in an interactive rebase
has conflicts and fails to apply, when the rebase is resumed that commit
will be squashed into its parent with its commit message taken.
The issue can be understood better by looking at commit 56dc3ab04b
("sequencer (rebase -i): implement the 'edit' command", 2017-01-02), which
introduced error_with_patch() for the edit command. For the edit command,
it needs to stop the rebase whether or not the patch applies cleanly. If
the patch does apply cleanly, then when it resumes it knows it needs to
amend all changes into the previous commit. If it does not apply cleanly,
then the changes should not be amended. Thus, it passes !res (success of
applying the 'edit' commit) to error_with_patch() for the to_amend flag.
The problematic line of code actually came from commit 04efc8b57c
("sequencer (rebase -i): implement the 'reword' command", 2017-01-02).
Note that to get to this point in the code:
* !!res (i.e. patch application failed)
* item->command < TODO_SQUASH
* item->command != TODO_EDIT
* !is_fixup(item->command) [i.e. not squash or fixup]
So that means this can only be a failed patch application that is either a
pick, revert, or reword. We only need to amend HEAD when rewording the
root commit or a commit that has been fast-forwarded, for any of the other
cases we want a new commit, so we should not set the to_amend flag.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Original-patch-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19 20:46:51 +08:00
|
|
|
res, to_amend);
|
|
|
|
|
}
|
2017-01-02 23:26:47 +08:00
|
|
|
} else if (item->command == TODO_EXEC) {
|
2019-01-29 23:01:46 +08:00
|
|
|
char *end_of_arg = (char *)(arg + item->arg_len);
|
2017-01-02 23:26:47 +08:00
|
|
|
int saved = *end_of_arg;
|
2017-04-27 03:17:40 +08:00
|
|
|
struct stat st;
|
2017-01-02 23:26:47 +08:00
|
|
|
|
rebase: fix garbled progress display with '-x'
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: true
Executing: true
Executing: true)
Successfully rebased and updated refs/heads/master.
Note the ')' at the end of the last line. It gets more garbled as the
range of commits increases:
$ git rebase -x true HEAD~50
Executing: true)
[ repeated 3 more times ]
Executing: true0)
[ repeated 44 more times ]
Executing: true00)
Successfully rebased and updated refs/heads/master.
Those extra numbers and ')' are remnants of the previously displayed
"Rebasing (N/M)" progress lines that are usually completely
overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and
the "N/M" part is long.
Make sure that the previously displayed "Rebasing (N/M)" line is
cleared by using the term_clear_line() helper function added in the
previous patch. Do so only when not being '--verbose', because in
that case these "Rebasing (N/M)" lines are not printed as progress
(i.e. as lines with '\r' at the end), but as "regular" output (with
'\n' at the end).
A couple of other rebase commands print similar messages, e.g.
"Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break'
commands, or the "Successfully rebased and updated <full-ref>." at the
very end. These are so long that they practically always overwrite
that "Rebasing (N/M)" progress line, but let's be prudent, and clear
the last line before printing these, too.
In 't3420-rebase-autostash.sh' two helper functions prepare the
expected output of four tests that check the full output of 'git
rebase' and thus are affected by this change, so adjust their
expectations to account for the new line clearing.
Note that this patch doesn't completely eliminate the possibility of
similar garbled outputs, e.g. some error messages from rebase or the
"Auto-merging <file>" message from within the depths of the merge
machinery might not be long enough to completely cover the last
"Rebasing (N/M)" line. This patch doesn't do anything about them,
because dealing with them individually would result in way too much
churn, while having a catch-all term_clear_line() call in the common
code path of pick_commits() would hide the "Rebasing (N/M)" line way
too soon, and it would either flicker or be invisible.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27 21:42:48 +08:00
|
|
|
if (!opts->verbose)
|
|
|
|
|
term_clear_line();
|
2017-01-02 23:26:47 +08:00
|
|
|
*end_of_arg = '\0';
|
2019-01-29 23:01:46 +08:00
|
|
|
res = do_exec(r, arg);
|
2017-01-02 23:26:47 +08:00
|
|
|
*end_of_arg = saved;
|
2017-04-27 03:17:40 +08:00
|
|
|
|
2018-12-11 03:04:58 +08:00
|
|
|
if (res) {
|
|
|
|
|
if (opts->reschedule_failed_exec)
|
|
|
|
|
reschedule = 1;
|
|
|
|
|
} else if (stat(get_todo_path(opts), &st))
|
2017-04-27 03:17:40 +08:00
|
|
|
res = error_errno(_("could not stat '%s'"),
|
|
|
|
|
get_todo_path(opts));
|
|
|
|
|
else if (match_stat_data(&todo_list->stat, &st)) {
|
2019-03-13 18:16:33 +08:00
|
|
|
/* Reread the todo file if it has changed. */
|
2017-04-27 03:17:40 +08:00
|
|
|
todo_list_release(todo_list);
|
2018-11-10 13:48:57 +08:00
|
|
|
if (read_populate_todo(r, todo_list, opts))
|
2017-04-27 03:17:40 +08:00
|
|
|
res = -1; /* message was printed */
|
|
|
|
|
/* `current` will be incremented below */
|
|
|
|
|
todo_list->current = -1;
|
|
|
|
|
}
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
} else if (item->command == TODO_LABEL) {
|
2019-01-29 23:01:46 +08:00
|
|
|
if ((res = do_label(r, arg, item->arg_len)))
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
reschedule = 1;
|
|
|
|
|
} else if (item->command == TODO_RESET) {
|
2019-01-29 23:01:46 +08:00
|
|
|
if ((res = do_reset(r, arg, item->arg_len, opts)))
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
reschedule = 1;
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
} else if (item->command == TODO_MERGE) {
|
2018-11-10 13:48:56 +08:00
|
|
|
if ((res = do_merge(r, item->commit,
|
2019-01-29 23:01:46 +08:00
|
|
|
arg, item->arg_len,
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
item->flags, opts)) < 0)
|
|
|
|
|
reschedule = 1;
|
2018-04-25 20:29:29 +08:00
|
|
|
else if (item->commit)
|
|
|
|
|
record_in_rewritten(&item->commit->object.oid,
|
|
|
|
|
peek_command(todo_list, 1));
|
|
|
|
|
if (res > 0)
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
/* failed with merge conflicts */
|
2018-11-10 13:48:56 +08:00
|
|
|
return error_with_patch(r, item->commit,
|
2019-01-29 23:01:46 +08:00
|
|
|
arg, item->arg_len,
|
|
|
|
|
opts, res, 0);
|
2017-01-02 23:26:43 +08:00
|
|
|
} else if (!is_noop(item->command))
|
2017-01-02 23:26:38 +08:00
|
|
|
return error(_("unknown command %d"), item->command);
|
|
|
|
|
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
if (reschedule) {
|
|
|
|
|
advise(_(rescheduled_advice),
|
|
|
|
|
get_item_line_length(todo_list,
|
|
|
|
|
todo_list->current),
|
|
|
|
|
get_item_line(todo_list, todo_list->current));
|
|
|
|
|
todo_list->current--;
|
|
|
|
|
if (save_todo(todo_list, opts))
|
|
|
|
|
return -1;
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
if (item->commit)
|
2018-11-10 13:48:56 +08:00
|
|
|
return error_with_patch(r,
|
|
|
|
|
item->commit,
|
2019-01-29 23:01:46 +08:00
|
|
|
arg, item->arg_len,
|
|
|
|
|
opts, res, 0);
|
sequencer: introduce new commands to reset the revision
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list commands, to support
labeling the current revision with a given name, resetting the current
revision to a previous state, and merging labeled revisions.
This idea was developed in Git for Windows' Git garden shears (that are
used to maintain Git for Windows' "thicket of branches" on top of
upstream Git), and this patch is part of the effort to make it available
to a wider audience, as well as to make the entire process more robust
(by implementing it in a safe and portable language rather than a Unix
shell script).
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label <name>
reset <name>
Internally, the `label <name>` command creates the ref
`refs/rewritten/<name>`. This makes it possible to work with the labeled
revisions interactively, or in a scripted fashion (e.g. via the todo
list command `exec`).
These temporary refs are removed upon sequencer_remove_state(), so that
even a `git rebase --abort` cleans them up.
We disallow '#' as label because that character will be used as separator
in the upcoming `merge` command.
Later in this patch series, we will mark the `refs/rewritten/` refs as
worktree-local, to allow for interactive rebases to be run in parallel in
worktrees linked to the same repository.
As typos happen, a failed `label` or `reset` command will be rescheduled
immediately. As the previous code to reschedule a command is embedded
deeply in the pick/fixup/squash code path, we simply duplicate the few
lines. This will allow us to extend the new code path easily for the
upcoming `merge` command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:47 +08:00
|
|
|
}
|
|
|
|
|
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
todo_list->current++;
|
2012-01-12 02:15:57 +08:00
|
|
|
if (res)
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:26:43 +08:00
|
|
|
if (is_rebase_i(opts)) {
|
2017-01-02 23:27:53 +08:00
|
|
|
struct strbuf head_ref = STRBUF_INIT, buf = STRBUF_INIT;
|
2017-01-02 23:28:16 +08:00
|
|
|
struct stat st;
|
2017-01-02 23:26:53 +08:00
|
|
|
|
2017-01-02 23:26:43 +08:00
|
|
|
/* Stopped in the middle, as planned? */
|
|
|
|
|
if (todo_list->current < todo_list->nr)
|
|
|
|
|
return 0;
|
2017-01-02 23:26:53 +08:00
|
|
|
|
2017-01-02 23:27:53 +08:00
|
|
|
if (read_oneliner(&head_ref, rebase_path_head_name(), 0) &&
|
|
|
|
|
starts_with(head_ref.buf, "refs/")) {
|
2017-01-02 23:28:09 +08:00
|
|
|
const char *msg;
|
2017-07-14 07:49:22 +08:00
|
|
|
struct object_id head, orig;
|
2017-01-02 23:27:53 +08:00
|
|
|
int res;
|
|
|
|
|
|
2017-07-14 07:49:22 +08:00
|
|
|
if (get_oid("HEAD", &head)) {
|
2017-01-02 23:27:53 +08:00
|
|
|
res = error(_("cannot read HEAD"));
|
|
|
|
|
cleanup_head_ref:
|
|
|
|
|
strbuf_release(&head_ref);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
if (!read_oneliner(&buf, rebase_path_orig_head(), 0) ||
|
2017-07-14 07:49:22 +08:00
|
|
|
get_oid_hex(buf.buf, &orig)) {
|
2017-01-02 23:27:53 +08:00
|
|
|
res = error(_("could not read orig-head"));
|
|
|
|
|
goto cleanup_head_ref;
|
|
|
|
|
}
|
2017-05-18 18:02:32 +08:00
|
|
|
strbuf_reset(&buf);
|
2017-01-02 23:27:53 +08:00
|
|
|
if (!read_oneliner(&buf, rebase_path_onto(), 0)) {
|
|
|
|
|
res = error(_("could not read 'onto'"));
|
|
|
|
|
goto cleanup_head_ref;
|
|
|
|
|
}
|
2017-01-02 23:28:09 +08:00
|
|
|
msg = reflog_message(opts, "finish", "%s onto %s",
|
|
|
|
|
head_ref.buf, buf.buf);
|
2017-10-16 06:06:51 +08:00
|
|
|
if (update_ref(msg, head_ref.buf, &head, &orig,
|
2017-11-05 16:42:06 +08:00
|
|
|
REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR)) {
|
2017-01-02 23:27:53 +08:00
|
|
|
res = error(_("could not update %s"),
|
|
|
|
|
head_ref.buf);
|
|
|
|
|
goto cleanup_head_ref;
|
|
|
|
|
}
|
2017-01-02 23:28:09 +08:00
|
|
|
msg = reflog_message(opts, "finish", "returning to %s",
|
2017-01-02 23:27:53 +08:00
|
|
|
head_ref.buf);
|
2017-01-02 23:28:09 +08:00
|
|
|
if (create_symref("HEAD", head_ref.buf, msg)) {
|
2017-01-02 23:27:53 +08:00
|
|
|
res = error(_("could not update HEAD to %s"),
|
|
|
|
|
head_ref.buf);
|
|
|
|
|
goto cleanup_head_ref;
|
|
|
|
|
}
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-02 23:26:53 +08:00
|
|
|
if (opts->verbose) {
|
|
|
|
|
struct rev_info log_tree_opt;
|
|
|
|
|
struct object_id orig, head;
|
|
|
|
|
|
|
|
|
|
memset(&log_tree_opt, 0, sizeof(log_tree_opt));
|
2018-11-10 13:48:56 +08:00
|
|
|
repo_init_revisions(r, &log_tree_opt, NULL);
|
2017-01-02 23:26:53 +08:00
|
|
|
log_tree_opt.diff = 1;
|
|
|
|
|
log_tree_opt.diffopt.output_format =
|
|
|
|
|
DIFF_FORMAT_DIFFSTAT;
|
|
|
|
|
log_tree_opt.disable_stdin = 1;
|
|
|
|
|
|
|
|
|
|
if (read_oneliner(&buf, rebase_path_orig_head(), 0) &&
|
sha1_name: convert get_sha1* to get_oid*
Now that all the callers of get_sha1 directly or indirectly use struct
object_id, rename the functions starting with get_sha1 to start with
get_oid. Convert the internals in sha1_name.c to use struct object_id
as well, and eliminate explicit length checks where possible. Convert a
use of 40 in get_oid_basic to GIT_SHA1_HEXSZ.
Outside of sha1_name.c and cache.h, this transition was made with the
following semantic patch:
@@
expression E1, E2;
@@
- get_sha1(E1, E2.hash)
+ get_oid(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1(E1, E2->hash)
+ get_oid(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_committish(E1, E2.hash)
+ get_oid_committish(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_committish(E1, E2->hash)
+ get_oid_committish(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_treeish(E1, E2.hash)
+ get_oid_treeish(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_treeish(E1, E2->hash)
+ get_oid_treeish(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_commit(E1, E2.hash)
+ get_oid_commit(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_commit(E1, E2->hash)
+ get_oid_commit(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_tree(E1, E2.hash)
+ get_oid_tree(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_tree(E1, E2->hash)
+ get_oid_tree(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_blob(E1, E2.hash)
+ get_oid_blob(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_blob(E1, E2->hash)
+ get_oid_blob(E1, E2)
@@
expression E1, E2, E3, E4;
@@
- get_sha1_with_context(E1, E2, E3.hash, E4)
+ get_oid_with_context(E1, E2, &E3, E4)
@@
expression E1, E2, E3, E4;
@@
- get_sha1_with_context(E1, E2, E3->hash, E4)
+ get_oid_with_context(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-14 07:49:28 +08:00
|
|
|
!get_oid(buf.buf, &orig) &&
|
|
|
|
|
!get_oid("HEAD", &head)) {
|
2017-05-31 01:31:03 +08:00
|
|
|
diff_tree_oid(&orig, &head, "",
|
|
|
|
|
&log_tree_opt.diffopt);
|
2017-01-02 23:26:53 +08:00
|
|
|
log_tree_diff_flush(&log_tree_opt);
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-01-02 23:28:16 +08:00
|
|
|
flush_rewritten_pending();
|
|
|
|
|
if (!stat(rebase_path_rewritten_list(), &st) &&
|
|
|
|
|
st.st_size > 0) {
|
|
|
|
|
struct child_process child = CHILD_PROCESS_INIT;
|
2017-01-02 23:28:23 +08:00
|
|
|
const char *post_rewrite_hook =
|
|
|
|
|
find_hook("post-rewrite");
|
2017-01-02 23:28:16 +08:00
|
|
|
|
|
|
|
|
child.in = open(rebase_path_rewritten_list(), O_RDONLY);
|
|
|
|
|
child.git_cmd = 1;
|
|
|
|
|
argv_array_push(&child.args, "notes");
|
|
|
|
|
argv_array_push(&child.args, "copy");
|
|
|
|
|
argv_array_push(&child.args, "--for-rewrite=rebase");
|
|
|
|
|
/* we don't care if this copying failed */
|
|
|
|
|
run_command(&child);
|
2017-01-02 23:28:23 +08:00
|
|
|
|
|
|
|
|
if (post_rewrite_hook) {
|
|
|
|
|
struct child_process hook = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
|
|
hook.in = open(rebase_path_rewritten_list(),
|
|
|
|
|
O_RDONLY);
|
|
|
|
|
hook.stdout_to_stderr = 1;
|
2019-02-23 06:25:06 +08:00
|
|
|
hook.trace2_hook_name = "post-rewrite";
|
2017-01-02 23:28:23 +08:00
|
|
|
argv_array_push(&hook.args, post_rewrite_hook);
|
|
|
|
|
argv_array_push(&hook.args, "rebase");
|
|
|
|
|
/* we don't care if this hook failed */
|
|
|
|
|
run_command(&hook);
|
|
|
|
|
}
|
2017-01-02 23:28:16 +08:00
|
|
|
}
|
2017-01-02 23:28:27 +08:00
|
|
|
apply_autostash(opts);
|
2017-01-02 23:28:16 +08:00
|
|
|
|
rebase: fix garbled progress display with '-x'
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: true
Executing: true
Executing: true)
Successfully rebased and updated refs/heads/master.
Note the ')' at the end of the last line. It gets more garbled as the
range of commits increases:
$ git rebase -x true HEAD~50
Executing: true)
[ repeated 3 more times ]
Executing: true0)
[ repeated 44 more times ]
Executing: true00)
Successfully rebased and updated refs/heads/master.
Those extra numbers and ')' are remnants of the previously displayed
"Rebasing (N/M)" progress lines that are usually completely
overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and
the "N/M" part is long.
Make sure that the previously displayed "Rebasing (N/M)" line is
cleared by using the term_clear_line() helper function added in the
previous patch. Do so only when not being '--verbose', because in
that case these "Rebasing (N/M)" lines are not printed as progress
(i.e. as lines with '\r' at the end), but as "regular" output (with
'\n' at the end).
A couple of other rebase commands print similar messages, e.g.
"Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break'
commands, or the "Successfully rebased and updated <full-ref>." at the
very end. These are so long that they practically always overwrite
that "Rebasing (N/M)" progress line, but let's be prudent, and clear
the last line before printing these, too.
In 't3420-rebase-autostash.sh' two helper functions prepare the
expected output of four tests that check the full output of 'git
rebase' and thus are affected by this change, so adjust their
expectations to account for the new line clearing.
Note that this patch doesn't completely eliminate the possibility of
similar garbled outputs, e.g. some error messages from rebase or the
"Auto-merging <file>" message from within the depths of the merge
machinery might not be long enough to completely cover the last
"Rebasing (N/M)" line. This patch doesn't do anything about them,
because dealing with them individually would result in way too much
churn, while having a catch-all term_clear_line() call in the common
code path of pick_commits() would hide the "Rebasing (N/M)" line way
too soon, and it would either flicker or be invisible.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27 21:42:48 +08:00
|
|
|
if (!opts->quiet) {
|
|
|
|
|
if (!opts->verbose)
|
|
|
|
|
term_clear_line();
|
git-rebase, sequencer: extend --quiet option for the interactive machinery
While 'quiet' and 'interactive' may sound like antonyms, the interactive
machinery actually has logic that implements several
interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
which won't pop up an editor. The rewrite of interactive rebase in C
added a quiet option, though it only turns stats off. Since we want to
make the interactive machinery also take over for git-rebase--merge, it
should fully implement the --quiet option.
git-rebase--interactive was already somewhat quieter than
git-rebase--merge and git-rebase--am, possibly because cherry-pick has
just traditionally been quieter. As such, we only drop a few
informational messages -- "Rebasing (n/m)" and "Successfully rebased..."
Also, for simplicity, remove the differences in how quiet and verbose
options were recorded. Having one be signalled by the presence of a
"verbose" file in the state_dir, while the other was signalled by the
contents of a "quiet" file was just weirdly inconsistent. (This
inconsistency pre-dated the rewrite into C.) Make them consistent by
having them both key off the presence of the file.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:36 +08:00
|
|
|
fprintf(stderr,
|
|
|
|
|
"Successfully rebased and updated %s.\n",
|
|
|
|
|
head_ref.buf);
|
rebase: fix garbled progress display with '-x'
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: true
Executing: true
Executing: true)
Successfully rebased and updated refs/heads/master.
Note the ')' at the end of the last line. It gets more garbled as the
range of commits increases:
$ git rebase -x true HEAD~50
Executing: true)
[ repeated 3 more times ]
Executing: true0)
[ repeated 44 more times ]
Executing: true00)
Successfully rebased and updated refs/heads/master.
Those extra numbers and ')' are remnants of the previously displayed
"Rebasing (N/M)" progress lines that are usually completely
overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and
the "N/M" part is long.
Make sure that the previously displayed "Rebasing (N/M)" line is
cleared by using the term_clear_line() helper function added in the
previous patch. Do so only when not being '--verbose', because in
that case these "Rebasing (N/M)" lines are not printed as progress
(i.e. as lines with '\r' at the end), but as "regular" output (with
'\n' at the end).
A couple of other rebase commands print similar messages, e.g.
"Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break'
commands, or the "Successfully rebased and updated <full-ref>." at the
very end. These are so long that they practically always overwrite
that "Rebasing (N/M)" progress line, but let's be prudent, and clear
the last line before printing these, too.
In 't3420-rebase-autostash.sh' two helper functions prepare the
expected output of four tests that check the full output of 'git
rebase' and thus are affected by this change, so adjust their
expectations to account for the new line clearing.
Note that this patch doesn't completely eliminate the possibility of
similar garbled outputs, e.g. some error messages from rebase or the
"Auto-merging <file>" message from within the depths of the merge
machinery might not be long enough to completely cover the last
"Rebasing (N/M)" line. This patch doesn't do anything about them,
because dealing with them individually would result in way too much
churn, while having a catch-all term_clear_line() call in the common
code path of pick_commits() would hide the "Rebasing (N/M)" line way
too soon, and it would either flicker or be invisible.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27 21:42:48 +08:00
|
|
|
}
|
2017-01-02 23:36:25 +08:00
|
|
|
|
2017-01-02 23:26:53 +08:00
|
|
|
strbuf_release(&buf);
|
2017-01-02 23:27:53 +08:00
|
|
|
strbuf_release(&head_ref);
|
2017-01-02 23:26:43 +08:00
|
|
|
}
|
|
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
/*
|
|
|
|
|
* Sequence of picks finished successfully; cleanup by
|
|
|
|
|
* removing the .git/sequencer directory
|
|
|
|
|
*/
|
2016-10-21 20:24:55 +08:00
|
|
|
return sequencer_remove_state(opts);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int continue_single_pick(struct repository *r)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
|
|
|
|
const char *argv[] = { "commit", NULL };
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
if (!file_exists(git_path_cherry_pick_head(r)) &&
|
|
|
|
|
!file_exists(git_path_revert_head(r)))
|
2012-01-12 02:15:57 +08:00
|
|
|
return error(_("no cherry-pick or revert in progress"));
|
|
|
|
|
return run_command_v_opt(argv, RUN_GIT_CMD);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int commit_staged_changes(struct repository *r,
|
|
|
|
|
struct replay_opts *opts,
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
struct todo_list *todo_list)
|
2017-01-02 23:27:21 +08:00
|
|
|
{
|
2017-03-24 00:07:11 +08:00
|
|
|
unsigned int flags = ALLOW_EMPTY | EDIT_MSG;
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
unsigned int final_fixup = 0, is_clean;
|
2017-01-02 23:27:21 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (has_unstaged_changes(r, 1))
|
2017-01-02 23:27:21 +08:00
|
|
|
return error(_("cannot rebase: You have unstaged changes."));
|
2017-01-02 23:27:25 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
is_clean = !has_uncommitted_changes(r, 0);
|
2017-01-02 23:27:21 +08:00
|
|
|
|
|
|
|
|
if (file_exists(rebase_path_amend())) {
|
|
|
|
|
struct strbuf rev = STRBUF_INIT;
|
2017-07-14 07:49:22 +08:00
|
|
|
struct object_id head, to_amend;
|
2017-01-02 23:27:21 +08:00
|
|
|
|
2017-07-14 07:49:22 +08:00
|
|
|
if (get_oid("HEAD", &head))
|
2017-01-02 23:27:21 +08:00
|
|
|
return error(_("cannot amend non-existing commit"));
|
|
|
|
|
if (!read_oneliner(&rev, rebase_path_amend(), 0))
|
|
|
|
|
return error(_("invalid file: '%s'"), rebase_path_amend());
|
2017-07-14 07:49:22 +08:00
|
|
|
if (get_oid_hex(rev.buf, &to_amend))
|
2017-01-02 23:27:21 +08:00
|
|
|
return error(_("invalid contents: '%s'"),
|
|
|
|
|
rebase_path_amend());
|
2018-08-29 05:22:48 +08:00
|
|
|
if (!is_clean && !oideq(&head, &to_amend))
|
2017-01-02 23:27:21 +08:00
|
|
|
return error(_("\nYou have uncommitted changes in your "
|
|
|
|
|
"working tree. Please, commit them\n"
|
|
|
|
|
"first and then run 'git rebase "
|
|
|
|
|
"--continue' again."));
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
/*
|
|
|
|
|
* When skipping a failed fixup/squash, we need to edit the
|
|
|
|
|
* commit message, the current fixup list and count, and if it
|
|
|
|
|
* was the last fixup/squash in the chain, we need to clean up
|
|
|
|
|
* the commit message and if there was a squash, let the user
|
|
|
|
|
* edit it.
|
|
|
|
|
*/
|
2018-09-01 07:45:04 +08:00
|
|
|
if (!is_clean || !opts->current_fixup_count)
|
|
|
|
|
; /* this is not the final fixup */
|
2018-09-25 01:30:45 +08:00
|
|
|
else if (!oideq(&head, &to_amend) ||
|
2018-09-01 07:45:04 +08:00
|
|
|
!file_exists(rebase_path_stopped_sha())) {
|
|
|
|
|
/* was a final fixup or squash done manually? */
|
|
|
|
|
if (!is_fixup(peek_command(todo_list, 0))) {
|
|
|
|
|
unlink(rebase_path_fixup_msg());
|
|
|
|
|
unlink(rebase_path_squash_msg());
|
|
|
|
|
unlink(rebase_path_current_fixups());
|
|
|
|
|
strbuf_reset(&opts->current_fixups);
|
|
|
|
|
opts->current_fixup_count = 0;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
/* we are in a fixup/squash chain */
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
const char *p = opts->current_fixups.buf;
|
|
|
|
|
int len = opts->current_fixups.len;
|
|
|
|
|
|
|
|
|
|
opts->current_fixup_count--;
|
|
|
|
|
if (!len)
|
|
|
|
|
BUG("Incorrect current_fixups:\n%s", p);
|
|
|
|
|
while (len && p[len - 1] != '\n')
|
|
|
|
|
len--;
|
|
|
|
|
strbuf_setlen(&opts->current_fixups, len);
|
|
|
|
|
if (write_message(p, len, rebase_path_current_fixups(),
|
|
|
|
|
0) < 0)
|
|
|
|
|
return error(_("could not write file: '%s'"),
|
|
|
|
|
rebase_path_current_fixups());
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If a fixup/squash in a fixup/squash chain failed, the
|
|
|
|
|
* commit message is already correct, no need to commit
|
|
|
|
|
* it again.
|
|
|
|
|
*
|
|
|
|
|
* Only if it is the final command in the fixup/squash
|
|
|
|
|
* chain, and only if the chain is longer than a single
|
|
|
|
|
* fixup/squash command (which was just skipped), do we
|
|
|
|
|
* actually need to re-commit with a cleaned up commit
|
|
|
|
|
* message.
|
|
|
|
|
*/
|
|
|
|
|
if (opts->current_fixup_count > 0 &&
|
|
|
|
|
!is_fixup(peek_command(todo_list, 0))) {
|
|
|
|
|
final_fixup = 1;
|
|
|
|
|
/*
|
|
|
|
|
* If there was not a single "squash" in the
|
|
|
|
|
* chain, we only need to clean up the commit
|
|
|
|
|
* message, no need to bother the user with
|
|
|
|
|
* opening the commit message in the editor.
|
|
|
|
|
*/
|
|
|
|
|
if (!starts_with(p, "squash ") &&
|
|
|
|
|
!strstr(p, "\nsquash "))
|
|
|
|
|
flags = (flags & ~EDIT_MSG) | CLEANUP_MSG;
|
|
|
|
|
} else if (is_fixup(peek_command(todo_list, 0))) {
|
|
|
|
|
/*
|
|
|
|
|
* We need to update the squash message to skip
|
|
|
|
|
* the latest commit message.
|
|
|
|
|
*/
|
|
|
|
|
struct commit *commit;
|
|
|
|
|
const char *path = rebase_path_squash_msg();
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
if (parse_head(r, &commit) ||
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
!(p = get_commit_buffer(commit, NULL)) ||
|
|
|
|
|
write_message(p, strlen(p), path, 0)) {
|
|
|
|
|
unuse_commit_buffer(commit, p);
|
|
|
|
|
return error(_("could not write file: "
|
|
|
|
|
"'%s'"), path);
|
|
|
|
|
}
|
|
|
|
|
unuse_commit_buffer(commit, p);
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-01-02 23:27:21 +08:00
|
|
|
|
|
|
|
|
strbuf_release(&rev);
|
2017-03-24 00:07:11 +08:00
|
|
|
flags |= AMEND_MSG;
|
2017-01-02 23:27:21 +08:00
|
|
|
}
|
|
|
|
|
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
if (is_clean) {
|
2018-11-10 13:48:56 +08:00
|
|
|
const char *cherry_pick_head = git_path_cherry_pick_head(r);
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
|
|
|
|
|
if (file_exists(cherry_pick_head) && unlink(cherry_pick_head))
|
|
|
|
|
return error(_("could not remove CHERRY_PICK_HEAD"));
|
|
|
|
|
if (!final_fixup)
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (run_git_commit(r, final_fixup ? NULL : rebase_path_message(),
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
opts, flags))
|
2017-01-02 23:27:21 +08:00
|
|
|
return error(_("could not commit staged changes."));
|
|
|
|
|
unlink(rebase_path_amend());
|
2019-06-27 17:28:52 +08:00
|
|
|
unlink(git_path_merge_head(r));
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
if (final_fixup) {
|
|
|
|
|
unlink(rebase_path_fixup_msg());
|
|
|
|
|
unlink(rebase_path_squash_msg());
|
|
|
|
|
}
|
|
|
|
|
if (opts->current_fixup_count > 0) {
|
|
|
|
|
/*
|
|
|
|
|
* Whether final fixup or not, we just cleaned up the commit
|
|
|
|
|
* message...
|
|
|
|
|
*/
|
|
|
|
|
unlink(rebase_path_current_fixups());
|
|
|
|
|
strbuf_reset(&opts->current_fixups);
|
|
|
|
|
opts->current_fixup_count = 0;
|
|
|
|
|
}
|
2017-01-02 23:27:21 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
int sequencer_continue(struct repository *r, struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
struct todo_list todo_list = TODO_LIST_INIT;
|
|
|
|
|
int res;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
if (read_and_refresh_cache(r, opts))
|
2016-10-21 20:24:55 +08:00
|
|
|
return -1;
|
|
|
|
|
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
if (read_populate_opts(opts))
|
|
|
|
|
return -1;
|
2017-01-02 23:27:21 +08:00
|
|
|
if (is_rebase_i(opts)) {
|
2018-11-10 13:48:57 +08:00
|
|
|
if ((res = read_populate_todo(r, &todo_list, opts)))
|
rebase --skip: clean up commit message after a failed fixup/squash
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
In any case, the commit message will be cleaned up eventually, removing
all those intermediate comments, in the final step of such a
fixup/squash chain.
However, if the last fixup/squash command in such a chain fails with
merge conflicts, and if the user then decides to skip it (or resolve it
to a clean worktree and then continue the rebase), the current code
fails to clean up the commit message.
This commit fixes that behavior.
The fix is quite a bit more involved than meets the eye because it is
not only about the question whether we are `git rebase --skip`ing a
fixup or squash. It is also about removing the skipped fixup/squash's
commit message from the accumulated commit message. And it is also about
the question whether we should let the user edit the final commit
message or not ("Was there a squash in the chain *that was not
skipped*?").
For example, in this case we will want to fix the commit message, but
not open it in an editor:
pick <- succeeds
fixup <- succeeds
squash <- fails, will be skipped
This is where the newly-introduced `current-fixups` file comes in real
handy. A quick look and we can determine whether there was a non-skipped
squash. We only need to make sure to keep it up to date with respect to
skipped fixup/squash commands. As a bonus, we can even avoid committing
unnecessarily, e.g. when there was only one fixup, and it failed, and
was skipped.
To fix only the bug where the final commit message was not cleaned up
properly, but without fixing the rest, would have been more complicated
than fixing it all in one go, hence this commit lumps together more than
a single concern.
For the same reason, this commit also adds a bit more to the existing
test case for the regression we just fixed.
The diff is best viewed with --color-moved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-28 04:48:30 +08:00
|
|
|
goto release_todo_list;
|
2018-11-10 13:48:56 +08:00
|
|
|
if (commit_staged_changes(r, opts, &todo_list))
|
2017-01-02 23:27:21 +08:00
|
|
|
return -1;
|
2017-01-02 23:27:30 +08:00
|
|
|
} else if (!file_exists(get_todo_path(opts)))
|
2018-11-10 13:48:57 +08:00
|
|
|
return continue_single_pick(r);
|
|
|
|
|
else if ((res = read_populate_todo(r, &todo_list, opts)))
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
goto release_todo_list;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2017-01-02 23:27:30 +08:00
|
|
|
if (!is_rebase_i(opts)) {
|
|
|
|
|
/* Verify that the conflict has been resolved */
|
2018-11-10 13:48:56 +08:00
|
|
|
if (file_exists(git_path_cherry_pick_head(r)) ||
|
|
|
|
|
file_exists(git_path_revert_head(r))) {
|
2018-11-10 13:48:57 +08:00
|
|
|
res = continue_single_pick(r);
|
2017-01-02 23:27:30 +08:00
|
|
|
if (res)
|
|
|
|
|
goto release_todo_list;
|
|
|
|
|
}
|
2018-11-10 13:49:04 +08:00
|
|
|
if (index_differs_from(r, "HEAD", NULL, 0)) {
|
2019-01-12 10:13:26 +08:00
|
|
|
res = error_dirty_index(r, opts);
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
goto release_todo_list;
|
2017-01-02 23:27:30 +08:00
|
|
|
}
|
|
|
|
|
todo_list.current++;
|
2017-01-02 23:28:20 +08:00
|
|
|
} else if (file_exists(rebase_path_stopped_sha())) {
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
struct object_id oid;
|
|
|
|
|
|
|
|
|
|
if (read_oneliner(&buf, rebase_path_stopped_sha(), 1) &&
|
sha1_name: convert get_sha1* to get_oid*
Now that all the callers of get_sha1 directly or indirectly use struct
object_id, rename the functions starting with get_sha1 to start with
get_oid. Convert the internals in sha1_name.c to use struct object_id
as well, and eliminate explicit length checks where possible. Convert a
use of 40 in get_oid_basic to GIT_SHA1_HEXSZ.
Outside of sha1_name.c and cache.h, this transition was made with the
following semantic patch:
@@
expression E1, E2;
@@
- get_sha1(E1, E2.hash)
+ get_oid(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1(E1, E2->hash)
+ get_oid(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_committish(E1, E2.hash)
+ get_oid_committish(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_committish(E1, E2->hash)
+ get_oid_committish(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_treeish(E1, E2.hash)
+ get_oid_treeish(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_treeish(E1, E2->hash)
+ get_oid_treeish(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_commit(E1, E2.hash)
+ get_oid_commit(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_commit(E1, E2->hash)
+ get_oid_commit(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_tree(E1, E2.hash)
+ get_oid_tree(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_tree(E1, E2->hash)
+ get_oid_tree(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_blob(E1, E2.hash)
+ get_oid_blob(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_blob(E1, E2->hash)
+ get_oid_blob(E1, E2)
@@
expression E1, E2, E3, E4;
@@
- get_sha1_with_context(E1, E2, E3.hash, E4)
+ get_oid_with_context(E1, E2, &E3, E4)
@@
expression E1, E2, E3, E4;
@@
- get_sha1_with_context(E1, E2, E3->hash, E4)
+ get_oid_with_context(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-14 07:49:28 +08:00
|
|
|
!get_oid_committish(buf.buf, &oid))
|
2017-01-02 23:28:20 +08:00
|
|
|
record_in_rewritten(&oid, peek_command(&todo_list, 0));
|
|
|
|
|
strbuf_release(&buf);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
2017-01-02 23:27:30 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
res = pick_commits(r, &todo_list, opts);
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
release_todo_list:
|
|
|
|
|
todo_list_release(&todo_list);
|
|
|
|
|
return res;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int single_pick(struct repository *r,
|
|
|
|
|
struct commit *cmit,
|
|
|
|
|
struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
|
|
|
|
setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
|
2018-11-10 13:48:56 +08:00
|
|
|
return do_pick_commit(r, opts->action == REPLAY_PICK ?
|
sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
single, final commit message edit, from the user's point of view), we
really have to implement them both at the same time.
Most of the actual work is done by the existing code path that already
handles the "pick" and the "edit" commands; We added support for other
features (e.g. to amend the commit message) in the patches leading up to
this one, yet there are still quite a few bits in this patch that simply
would not make sense as individual patches (such as: determining whether
there was anything to "fix up" in the "todo" script, etc).
In theory, it would be possible to reuse the fast-forward code path also
for the fixup and the squash code paths, but in practice this would make
the code less readable. The end result cannot be fast-forwarded anyway,
therefore let's just extend the cherry-picking code path for now.
Since the sequencer parses the entire `git-rebase-todo` script in one go,
fixup or squash commands without a preceding pick can be reported early
(in git-rebase--interactive, we could only report such errors just before
executing the fixup/squash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-02 23:27:07 +08:00
|
|
|
TODO_PICK : TODO_REVERT, cmit, opts, 0);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
int sequencer_pick_revisions(struct repository *r,
|
|
|
|
|
struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
struct todo_list todo_list = TODO_LIST_INIT;
|
2017-05-07 06:10:09 +08:00
|
|
|
struct object_id oid;
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
int i, res;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2016-10-21 20:24:55 +08:00
|
|
|
assert(opts->revs);
|
2018-11-10 13:48:56 +08:00
|
|
|
if (read_and_refresh_cache(r, opts))
|
2016-09-09 22:37:21 +08:00
|
|
|
return -1;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2013-04-11 21:06:52 +08:00
|
|
|
for (i = 0; i < opts->revs->pending.nr; i++) {
|
2017-05-07 06:10:09 +08:00
|
|
|
struct object_id oid;
|
2013-04-11 21:06:52 +08:00
|
|
|
const char *name = opts->revs->pending.objects[i].name;
|
|
|
|
|
|
|
|
|
|
/* This happens when using --stdin. */
|
|
|
|
|
if (!strlen(name))
|
|
|
|
|
continue;
|
|
|
|
|
|
2017-05-07 06:10:09 +08:00
|
|
|
if (!get_oid(name, &oid)) {
|
2018-11-10 13:48:56 +08:00
|
|
|
if (!lookup_commit_reference_gently(r, &oid, 1)) {
|
|
|
|
|
enum object_type type = oid_object_info(r,
|
2018-04-26 02:20:59 +08:00
|
|
|
&oid,
|
sha1_file: convert sha1_object_info* to object_id
Convert sha1_object_info and sha1_object_info_extended to take pointers
to struct object_id and rename them to use "oid" instead of "sha1" in
their names. Update the declaration and definition and apply the
following semantic patch, plus the standard object_id transforms:
@@
expression E1, E2;
@@
- sha1_object_info(E1.hash, E2)
+ oid_object_info(&E1, E2)
@@
expression E1, E2;
@@
- sha1_object_info(E1->hash, E2)
+ oid_object_info(E1, E2)
@@
expression E1, E2, E3;
@@
- sha1_object_info_extended(E1.hash, E2, E3)
+ oid_object_info_extended(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- sha1_object_info_extended(E1->hash, E2, E3)
+ oid_object_info_extended(E1, E2, E3)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 10:27:46 +08:00
|
|
|
NULL);
|
2016-08-26 21:47:10 +08:00
|
|
|
return error(_("%s: can't cherry-pick a %s"),
|
2018-02-15 02:59:24 +08:00
|
|
|
name, type_name(type));
|
2013-05-10 04:27:49 +08:00
|
|
|
}
|
2013-04-11 21:06:52 +08:00
|
|
|
} else
|
2016-08-26 21:47:10 +08:00
|
|
|
return error(_("%s: bad revision"), name);
|
2013-04-11 21:06:52 +08:00
|
|
|
}
|
|
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
/*
|
|
|
|
|
* If we were called as "git cherry-pick <commit>", just
|
|
|
|
|
* cherry-pick/revert it, set CHERRY_PICK_HEAD /
|
|
|
|
|
* REVERT_HEAD, and don't touch the sequencer state.
|
|
|
|
|
* This means it is possible to cherry-pick in the middle
|
|
|
|
|
* of a cherry-pick sequence.
|
|
|
|
|
*/
|
|
|
|
|
if (opts->revs->cmdline.nr == 1 &&
|
|
|
|
|
opts->revs->cmdline.rev->whence == REV_CMD_REV &&
|
|
|
|
|
opts->revs->no_walk &&
|
|
|
|
|
!opts->revs->cmdline.rev->flags) {
|
|
|
|
|
struct commit *cmit;
|
|
|
|
|
if (prepare_revision_walk(opts->revs))
|
2016-08-26 21:47:10 +08:00
|
|
|
return error(_("revision walk setup failed"));
|
2012-01-12 02:15:57 +08:00
|
|
|
cmit = get_revision(opts->revs);
|
2018-07-10 12:32:08 +08:00
|
|
|
if (!cmit)
|
|
|
|
|
return error(_("empty commit set passed"));
|
|
|
|
|
if (get_revision(opts->revs))
|
|
|
|
|
BUG("unexpected extra commit from walk");
|
2018-11-10 13:48:56 +08:00
|
|
|
return single_pick(r, cmit, opts);
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Start a new cherry-pick/ revert sequence; but
|
|
|
|
|
* first, make sure that an existing one isn't in
|
|
|
|
|
* progress
|
|
|
|
|
*/
|
|
|
|
|
|
2016-09-09 22:37:15 +08:00
|
|
|
if (walk_revs_populate_todo(&todo_list, opts) ||
|
2019-07-02 17:11:25 +08:00
|
|
|
create_seq_dir(r) < 0)
|
2012-01-12 02:15:57 +08:00
|
|
|
return -1;
|
2017-05-07 06:10:09 +08:00
|
|
|
if (get_oid("HEAD", &oid) && (opts->action == REPLAY_REVERT))
|
2016-10-21 20:26:25 +08:00
|
|
|
return error(_("can't revert as initial commit"));
|
2017-05-07 06:10:09 +08:00
|
|
|
if (save_head(oid_to_hex(&oid)))
|
2016-09-09 22:37:47 +08:00
|
|
|
return -1;
|
2016-09-09 22:37:53 +08:00
|
|
|
if (save_opts(opts))
|
|
|
|
|
return -1;
|
2016-12-08 05:51:32 +08:00
|
|
|
update_abort_safety_file();
|
2018-11-10 13:48:56 +08:00
|
|
|
res = pick_commits(r, &todo_list, opts);
|
sequencer: completely revamp the "todo" script parsing
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was used as working horse for
cherry-pick and revert instead. So as not to interfere with the
interactive rebase, it even uses a separate directory to store its
state.
Furthermore, it also is stupidly strict about the "todo" script it
accepts: while it parses commands in a way that was *designed* to be
similar to the interactive rebase, it then goes on to *error out* if the
commands disagree with the overall action (cherry-pick or revert).
Finally, the sequencer code chose to deviate from the interactive rebase
code insofar that when it comes to writing the file with the remaining
commands, it *reformats* the "todo" script instead of just writing the
part of the parsed script that were not yet processed. This is not only
unnecessary churn, but might well lose information that is valuable to
the user (i.e. comments after the commands).
Let's just bite the bullet and rewrite the entire parser; the code now
becomes not only more elegant: it allows us to go on and teach the
sequencer how to parse *true* "todo" scripts as used by the interactive
rebase itself. In a way, the sequencer is about to grow up to do its
older brother's job. Better.
In particular, we choose to maintain the list of commands in an array
instead of a linked list: this is flexible enough to allow us later on to
even implement rebase -i's reordering of fixup!/squash! commits very
easily (and with a very nice speed bonus, at least on Windows).
While at it, do not stop at the first problem, but list *all* of the
problems. This will help the user when the sequencer will do `rebase
-i`'s work by allowing to address all issues in one go rather than going
back and forth until the todo list is valid.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21 20:24:41 +08:00
|
|
|
todo_list_release(&todo_list);
|
|
|
|
|
return res;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
2012-09-14 14:52:03 +08:00
|
|
|
|
2018-08-23 08:50:51 +08:00
|
|
|
void append_signoff(struct strbuf *msgbuf, size_t ignore_footer, unsigned flag)
|
2012-09-14 14:52:03 +08:00
|
|
|
{
|
2013-02-12 18:17:35 +08:00
|
|
|
unsigned no_dup_sob = flag & APPEND_SIGNOFF_DEDUP;
|
2012-09-14 14:52:03 +08:00
|
|
|
struct strbuf sob = STRBUF_INIT;
|
2013-02-12 18:17:35 +08:00
|
|
|
int has_footer;
|
2012-09-14 14:52:03 +08:00
|
|
|
|
|
|
|
|
strbuf_addstr(&sob, sign_off_header);
|
2019-02-05 02:48:50 +08:00
|
|
|
strbuf_addstr(&sob, fmt_name(WANT_COMMITTER_IDENT));
|
2012-09-14 14:52:03 +08:00
|
|
|
strbuf_addch(&sob, '\n');
|
2013-02-12 18:17:35 +08:00
|
|
|
|
2017-04-27 04:50:03 +08:00
|
|
|
if (!ignore_footer)
|
|
|
|
|
strbuf_complete_line(msgbuf);
|
|
|
|
|
|
2013-02-12 18:17:35 +08:00
|
|
|
/*
|
|
|
|
|
* If the whole message buffer is equal to the sob, pretend that we
|
|
|
|
|
* found a conforming footer with a matching sob
|
|
|
|
|
*/
|
|
|
|
|
if (msgbuf->len - ignore_footer == sob.len &&
|
|
|
|
|
!strncmp(msgbuf->buf, sob.buf, sob.len))
|
|
|
|
|
has_footer = 3;
|
|
|
|
|
else
|
|
|
|
|
has_footer = has_conforming_footer(msgbuf, &sob, ignore_footer);
|
|
|
|
|
|
2013-02-12 18:33:42 +08:00
|
|
|
if (!has_footer) {
|
|
|
|
|
const char *append_newlines = NULL;
|
|
|
|
|
size_t len = msgbuf->len - ignore_footer;
|
|
|
|
|
|
2013-02-23 06:05:27 +08:00
|
|
|
if (!len) {
|
|
|
|
|
/*
|
|
|
|
|
* The buffer is completely empty. Leave foom for
|
|
|
|
|
* the title and body to be filled in by the user.
|
|
|
|
|
*/
|
2013-02-12 18:33:42 +08:00
|
|
|
append_newlines = "\n\n";
|
2013-02-23 06:05:27 +08:00
|
|
|
} else if (len == 1) {
|
|
|
|
|
/*
|
|
|
|
|
* Buffer contains a single newline. Add another
|
|
|
|
|
* so that we leave room for the title and body.
|
|
|
|
|
*/
|
|
|
|
|
append_newlines = "\n";
|
|
|
|
|
} else if (msgbuf->buf[len - 2] != '\n') {
|
|
|
|
|
/*
|
|
|
|
|
* Buffer ends with a single newline. Add another
|
|
|
|
|
* so that there is an empty line between the message
|
|
|
|
|
* body and the sob.
|
|
|
|
|
*/
|
2013-02-12 18:33:42 +08:00
|
|
|
append_newlines = "\n";
|
2013-02-23 06:05:27 +08:00
|
|
|
} /* else, the buffer already ends with two newlines. */
|
2013-02-12 18:33:42 +08:00
|
|
|
|
|
|
|
|
if (append_newlines)
|
|
|
|
|
strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
|
|
|
|
|
append_newlines, strlen(append_newlines));
|
2012-09-14 14:52:03 +08:00
|
|
|
}
|
2013-02-12 18:17:35 +08:00
|
|
|
|
|
|
|
|
if (has_footer != 3 && (!no_dup_sob || has_footer != 2))
|
|
|
|
|
strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
|
|
|
|
|
sob.buf, sob.len);
|
|
|
|
|
|
2012-09-14 14:52:03 +08:00
|
|
|
strbuf_release(&sob);
|
|
|
|
|
}
|
2017-07-14 22:44:58 +08:00
|
|
|
|
2018-04-25 20:29:03 +08:00
|
|
|
struct labels_entry {
|
|
|
|
|
struct hashmap_entry entry;
|
|
|
|
|
char label[FLEX_ARRAY];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int labels_cmp(const void *fndata, const struct labels_entry *a,
|
|
|
|
|
const struct labels_entry *b, const void *key)
|
|
|
|
|
{
|
|
|
|
|
return key ? strcmp(a->label, key) : strcmp(a->label, b->label);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct string_entry {
|
|
|
|
|
struct oidmap_entry entry;
|
|
|
|
|
char string[FLEX_ARRAY];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct label_state {
|
|
|
|
|
struct oidmap commit2label;
|
|
|
|
|
struct hashmap labels;
|
|
|
|
|
struct strbuf buf;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const char *label_oid(struct object_id *oid, const char *label,
|
|
|
|
|
struct label_state *state)
|
|
|
|
|
{
|
|
|
|
|
struct labels_entry *labels_entry;
|
|
|
|
|
struct string_entry *string_entry;
|
|
|
|
|
struct object_id dummy;
|
|
|
|
|
size_t len;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
string_entry = oidmap_get(&state->commit2label, oid);
|
|
|
|
|
if (string_entry)
|
|
|
|
|
return string_entry->string;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* For "uninteresting" commits, i.e. commits that are not to be
|
|
|
|
|
* rebased, and which can therefore not be labeled, we use a unique
|
|
|
|
|
* abbreviation of the commit name. This is slightly more complicated
|
|
|
|
|
* than calling find_unique_abbrev() because we also need to make
|
|
|
|
|
* sure that the abbreviation does not conflict with any other
|
|
|
|
|
* label.
|
|
|
|
|
*
|
|
|
|
|
* We disallow "interesting" commits to be labeled by a string that
|
|
|
|
|
* is a valid full-length hash, to ensure that we always can find an
|
|
|
|
|
* abbreviation for any uninteresting commit's names that does not
|
|
|
|
|
* clash with any other label.
|
|
|
|
|
*/
|
|
|
|
|
if (!label) {
|
|
|
|
|
char *p;
|
|
|
|
|
|
|
|
|
|
strbuf_reset(&state->buf);
|
|
|
|
|
strbuf_grow(&state->buf, GIT_SHA1_HEXSZ);
|
|
|
|
|
label = p = state->buf.buf;
|
|
|
|
|
|
|
|
|
|
find_unique_abbrev_r(p, oid, default_abbrev);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We may need to extend the abbreviated hash so that there is
|
|
|
|
|
* no conflicting label.
|
|
|
|
|
*/
|
|
|
|
|
if (hashmap_get_from_hash(&state->labels, strihash(p), p)) {
|
|
|
|
|
size_t i = strlen(p) + 1;
|
|
|
|
|
|
|
|
|
|
oid_to_hex_r(p, oid);
|
|
|
|
|
for (; i < GIT_SHA1_HEXSZ; i++) {
|
|
|
|
|
char save = p[i];
|
|
|
|
|
p[i] = '\0';
|
|
|
|
|
if (!hashmap_get_from_hash(&state->labels,
|
|
|
|
|
strihash(p), p))
|
|
|
|
|
break;
|
|
|
|
|
p[i] = save;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-05-30 00:32:36 +08:00
|
|
|
} else if (((len = strlen(label)) == the_hash_algo->hexsz &&
|
2018-04-25 20:29:03 +08:00
|
|
|
!get_oid_hex(label, &dummy)) ||
|
|
|
|
|
(len == 1 && *label == '#') ||
|
|
|
|
|
hashmap_get_from_hash(&state->labels,
|
|
|
|
|
strihash(label), label)) {
|
|
|
|
|
/*
|
|
|
|
|
* If the label already exists, or if the label is a valid full
|
|
|
|
|
* OID, or the label is a '#' (which we use as a separator
|
|
|
|
|
* between merge heads and oneline), we append a dash and a
|
|
|
|
|
* number to make it unique.
|
|
|
|
|
*/
|
|
|
|
|
struct strbuf *buf = &state->buf;
|
|
|
|
|
|
|
|
|
|
strbuf_reset(buf);
|
|
|
|
|
strbuf_add(buf, label, len);
|
|
|
|
|
|
|
|
|
|
for (i = 2; ; i++) {
|
|
|
|
|
strbuf_setlen(buf, len);
|
|
|
|
|
strbuf_addf(buf, "-%d", i);
|
|
|
|
|
if (!hashmap_get_from_hash(&state->labels,
|
|
|
|
|
strihash(buf->buf),
|
|
|
|
|
buf->buf))
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
label = buf->buf;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
FLEX_ALLOC_STR(labels_entry, label, label);
|
|
|
|
|
hashmap_entry_init(labels_entry, strihash(label));
|
|
|
|
|
hashmap_add(&state->labels, labels_entry);
|
|
|
|
|
|
|
|
|
|
FLEX_ALLOC_STR(string_entry, string, label);
|
|
|
|
|
oidcpy(&string_entry->entry.oid, oid);
|
|
|
|
|
oidmap_put(&state->commit2label, string_entry);
|
|
|
|
|
|
|
|
|
|
return string_entry->string;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int make_script_with_merges(struct pretty_print_context *pp,
|
2019-03-06 03:17:56 +08:00
|
|
|
struct rev_info *revs, struct strbuf *out,
|
2018-04-25 20:29:03 +08:00
|
|
|
unsigned flags)
|
|
|
|
|
{
|
|
|
|
|
int keep_empty = flags & TODO_LIST_KEEP_EMPTY;
|
rebase -i: introduce --rebase-merges=[no-]rebase-cousins
When running `git rebase --rebase-merges` non-interactively with an
ancestor of HEAD as <upstream> (or leaving the todo list unmodified),
we would ideally recreate the exact same commits as before the rebase.
However, if there are commits in the commit range <upstream>.. that do not
have <upstream> as direct ancestor (i.e. if `git log <upstream>..` would
show commits that are omitted by `git log --ancestry-path <upstream>..`),
this is currently not the case: we would turn them into commits that have
<upstream> as direct ancestor.
Let's illustrate that with a diagram:
C
/ \
A - B - E - F
\ /
D
Currently, after running `git rebase -i --rebase-merges B`, the new branch
structure would be (pay particular attention to the commit `D`):
--- C' --
/ \
A - B ------ E' - F'
\ /
D'
This is not really preserving the branch topology from before! The
reason is that the commit `D` does not have `B` as ancestor, and
therefore it gets rebased onto `B`.
This is unintuitive behavior. Even worse, when recreating branch
structure, most use cases would appear to want cousins *not* to be
rebased onto the new base commit. For example, Git for Windows (the
heaviest user of the Git garden shears, which served as the blueprint
for --rebase-merges) frequently merges branches from `next` early, and
these branches certainly do *not* want to be rebased. In the example
above, the desired outcome would look like this:
--- C' --
/ \
A - B ------ E' - F'
\ /
-- D' --
Let's introduce the term "cousins" for such commits ("D" in the
example), and let's not rebase them by default. For hypothetical
use cases where cousins *do* need to be rebased, `git rebase
--rebase=merges=rebase-cousins` needs to be used.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:29:40 +08:00
|
|
|
int rebase_cousins = flags & TODO_LIST_REBASE_COUSINS;
|
2018-04-25 20:29:03 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT, oneline = STRBUF_INIT;
|
|
|
|
|
struct strbuf label = STRBUF_INIT;
|
|
|
|
|
struct commit_list *commits = NULL, **tail = &commits, *iter;
|
|
|
|
|
struct commit_list *tips = NULL, **tips_tail = &tips;
|
|
|
|
|
struct commit *commit;
|
|
|
|
|
struct oidmap commit2todo = OIDMAP_INIT;
|
|
|
|
|
struct string_entry *entry;
|
|
|
|
|
struct oidset interesting = OIDSET_INIT, child_seen = OIDSET_INIT,
|
|
|
|
|
shown = OIDSET_INIT;
|
|
|
|
|
struct label_state state = { OIDMAP_INIT, { NULL }, STRBUF_INIT };
|
|
|
|
|
|
|
|
|
|
int abbr = flags & TODO_LIST_ABBREVIATE_CMDS;
|
|
|
|
|
const char *cmd_pick = abbr ? "p" : "pick",
|
|
|
|
|
*cmd_label = abbr ? "l" : "label",
|
|
|
|
|
*cmd_reset = abbr ? "t" : "reset",
|
|
|
|
|
*cmd_merge = abbr ? "m" : "merge";
|
|
|
|
|
|
|
|
|
|
oidmap_init(&commit2todo, 0);
|
|
|
|
|
oidmap_init(&state.commit2label, 0);
|
|
|
|
|
hashmap_init(&state.labels, (hashmap_cmp_fn) labels_cmp, NULL, 0);
|
|
|
|
|
strbuf_init(&state.buf, 32);
|
|
|
|
|
|
|
|
|
|
if (revs->cmdline.nr && (revs->cmdline.rev[0].flags & BOTTOM)) {
|
|
|
|
|
struct object_id *oid = &revs->cmdline.rev[0].item->oid;
|
|
|
|
|
FLEX_ALLOC_STR(entry, string, "onto");
|
|
|
|
|
oidcpy(&entry->entry.oid, oid);
|
|
|
|
|
oidmap_put(&state.commit2label, entry);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* First phase:
|
|
|
|
|
* - get onelines for all commits
|
|
|
|
|
* - gather all branch tips (i.e. 2nd or later parents of merges)
|
|
|
|
|
* - label all branch tips
|
|
|
|
|
*/
|
|
|
|
|
while ((commit = get_revision(revs))) {
|
|
|
|
|
struct commit_list *to_merge;
|
|
|
|
|
const char *p1, *p2;
|
|
|
|
|
struct object_id *oid;
|
|
|
|
|
int is_empty;
|
|
|
|
|
|
|
|
|
|
tail = &commit_list_insert(commit, tail)->next;
|
|
|
|
|
oidset_insert(&interesting, &commit->object.oid);
|
|
|
|
|
|
|
|
|
|
is_empty = is_original_commit_empty(commit);
|
|
|
|
|
if (!is_empty && (commit->object.flags & PATCHSAME))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
strbuf_reset(&oneline);
|
|
|
|
|
pretty_print_commit(pp, commit, &oneline);
|
|
|
|
|
|
|
|
|
|
to_merge = commit->parents ? commit->parents->next : NULL;
|
|
|
|
|
if (!to_merge) {
|
|
|
|
|
/* non-merge commit: easy case */
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
if (!keep_empty && is_empty)
|
|
|
|
|
strbuf_addf(&buf, "%c ", comment_line_char);
|
|
|
|
|
strbuf_addf(&buf, "%s %s %s", cmd_pick,
|
|
|
|
|
oid_to_hex(&commit->object.oid),
|
|
|
|
|
oneline.buf);
|
|
|
|
|
|
|
|
|
|
FLEX_ALLOC_STR(entry, string, buf.buf);
|
|
|
|
|
oidcpy(&entry->entry.oid, &commit->object.oid);
|
|
|
|
|
oidmap_put(&commit2todo, entry);
|
|
|
|
|
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Create a label */
|
|
|
|
|
strbuf_reset(&label);
|
|
|
|
|
if (skip_prefix(oneline.buf, "Merge ", &p1) &&
|
|
|
|
|
(p1 = strchr(p1, '\'')) &&
|
|
|
|
|
(p2 = strchr(++p1, '\'')))
|
|
|
|
|
strbuf_add(&label, p1, p2 - p1);
|
|
|
|
|
else if (skip_prefix(oneline.buf, "Merge pull request ",
|
|
|
|
|
&p1) &&
|
|
|
|
|
(p1 = strstr(p1, " from ")))
|
|
|
|
|
strbuf_addstr(&label, p1 + strlen(" from "));
|
|
|
|
|
else
|
|
|
|
|
strbuf_addbuf(&label, &oneline);
|
|
|
|
|
|
|
|
|
|
for (p1 = label.buf; *p1; p1++)
|
|
|
|
|
if (isspace(*p1))
|
|
|
|
|
*(char *)p1 = '-';
|
|
|
|
|
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
strbuf_addf(&buf, "%s -C %s",
|
|
|
|
|
cmd_merge, oid_to_hex(&commit->object.oid));
|
|
|
|
|
|
2017-12-21 22:52:45 +08:00
|
|
|
/* label the tips of merged branches */
|
|
|
|
|
for (; to_merge; to_merge = to_merge->next) {
|
|
|
|
|
oid = &to_merge->item->object.oid;
|
|
|
|
|
strbuf_addch(&buf, ' ');
|
|
|
|
|
|
|
|
|
|
if (!oidset_contains(&interesting, oid)) {
|
|
|
|
|
strbuf_addstr(&buf, label_oid(oid, NULL,
|
|
|
|
|
&state));
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2018-04-25 20:29:03 +08:00
|
|
|
|
|
|
|
|
tips_tail = &commit_list_insert(to_merge->item,
|
|
|
|
|
tips_tail)->next;
|
|
|
|
|
|
|
|
|
|
strbuf_addstr(&buf, label_oid(oid, label.buf, &state));
|
|
|
|
|
}
|
|
|
|
|
strbuf_addf(&buf, " # %s", oneline.buf);
|
|
|
|
|
|
|
|
|
|
FLEX_ALLOC_STR(entry, string, buf.buf);
|
|
|
|
|
oidcpy(&entry->entry.oid, &commit->object.oid);
|
|
|
|
|
oidmap_put(&commit2todo, entry);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Second phase:
|
|
|
|
|
* - label branch points
|
|
|
|
|
* - add HEAD to the branch tips
|
|
|
|
|
*/
|
|
|
|
|
for (iter = commits; iter; iter = iter->next) {
|
|
|
|
|
struct commit_list *parent = iter->item->parents;
|
|
|
|
|
for (; parent; parent = parent->next) {
|
|
|
|
|
struct object_id *oid = &parent->item->object.oid;
|
|
|
|
|
if (!oidset_contains(&interesting, oid))
|
|
|
|
|
continue;
|
2018-10-03 21:06:49 +08:00
|
|
|
if (oidset_insert(&child_seen, oid))
|
2018-04-25 20:29:03 +08:00
|
|
|
label_oid(oid, "branch-point", &state);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add HEAD as implict "tip of branch" */
|
|
|
|
|
if (!iter->next)
|
|
|
|
|
tips_tail = &commit_list_insert(iter->item,
|
|
|
|
|
tips_tail)->next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Third phase: output the todo list. This is a bit tricky, as we
|
|
|
|
|
* want to avoid jumping back and forth between revisions. To
|
|
|
|
|
* accomplish that goal, we walk backwards from the branch tips,
|
|
|
|
|
* gathering commits not yet shown, reversing the list on the fly,
|
|
|
|
|
* then outputting that list (labeling revisions as needed).
|
|
|
|
|
*/
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addf(out, "%s onto\n", cmd_label);
|
2018-04-25 20:29:03 +08:00
|
|
|
for (iter = tips; iter; iter = iter->next) {
|
|
|
|
|
struct commit_list *list = NULL, *iter2;
|
|
|
|
|
|
|
|
|
|
commit = iter->item;
|
|
|
|
|
if (oidset_contains(&shown, &commit->object.oid))
|
|
|
|
|
continue;
|
|
|
|
|
entry = oidmap_get(&state.commit2label, &commit->object.oid);
|
|
|
|
|
|
|
|
|
|
if (entry)
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addf(out, "\n%c Branch %s\n", comment_line_char, entry->string);
|
2018-04-25 20:29:03 +08:00
|
|
|
else
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addch(out, '\n');
|
2018-04-25 20:29:03 +08:00
|
|
|
|
|
|
|
|
while (oidset_contains(&interesting, &commit->object.oid) &&
|
|
|
|
|
!oidset_contains(&shown, &commit->object.oid)) {
|
|
|
|
|
commit_list_insert(commit, &list);
|
|
|
|
|
if (!commit->parents) {
|
|
|
|
|
commit = NULL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
commit = commit->parents->item;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!commit)
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addf(out, "%s %s\n", cmd_reset,
|
|
|
|
|
rebase_cousins ? "onto" : "[new root]");
|
2018-04-25 20:29:03 +08:00
|
|
|
else {
|
|
|
|
|
const char *to = NULL;
|
|
|
|
|
|
|
|
|
|
entry = oidmap_get(&state.commit2label,
|
|
|
|
|
&commit->object.oid);
|
|
|
|
|
if (entry)
|
|
|
|
|
to = entry->string;
|
rebase -i: introduce --rebase-merges=[no-]rebase-cousins
When running `git rebase --rebase-merges` non-interactively with an
ancestor of HEAD as <upstream> (or leaving the todo list unmodified),
we would ideally recreate the exact same commits as before the rebase.
However, if there are commits in the commit range <upstream>.. that do not
have <upstream> as direct ancestor (i.e. if `git log <upstream>..` would
show commits that are omitted by `git log --ancestry-path <upstream>..`),
this is currently not the case: we would turn them into commits that have
<upstream> as direct ancestor.
Let's illustrate that with a diagram:
C
/ \
A - B - E - F
\ /
D
Currently, after running `git rebase -i --rebase-merges B`, the new branch
structure would be (pay particular attention to the commit `D`):
--- C' --
/ \
A - B ------ E' - F'
\ /
D'
This is not really preserving the branch topology from before! The
reason is that the commit `D` does not have `B` as ancestor, and
therefore it gets rebased onto `B`.
This is unintuitive behavior. Even worse, when recreating branch
structure, most use cases would appear to want cousins *not* to be
rebased onto the new base commit. For example, Git for Windows (the
heaviest user of the Git garden shears, which served as the blueprint
for --rebase-merges) frequently merges branches from `next` early, and
these branches certainly do *not* want to be rebased. In the example
above, the desired outcome would look like this:
--- C' --
/ \
A - B ------ E' - F'
\ /
-- D' --
Let's introduce the term "cousins" for such commits ("D" in the
example), and let's not rebase them by default. For hypothetical
use cases where cousins *do* need to be rebased, `git rebase
--rebase=merges=rebase-cousins` needs to be used.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:29:40 +08:00
|
|
|
else if (!rebase_cousins)
|
|
|
|
|
to = label_oid(&commit->object.oid, NULL,
|
|
|
|
|
&state);
|
2018-04-25 20:29:03 +08:00
|
|
|
|
|
|
|
|
if (!to || !strcmp(to, "onto"))
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addf(out, "%s onto\n", cmd_reset);
|
2018-04-25 20:29:03 +08:00
|
|
|
else {
|
|
|
|
|
strbuf_reset(&oneline);
|
|
|
|
|
pretty_print_commit(pp, commit, &oneline);
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addf(out, "%s %s # %s\n",
|
|
|
|
|
cmd_reset, to, oneline.buf);
|
2018-04-25 20:29:03 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (iter2 = list; iter2; iter2 = iter2->next) {
|
|
|
|
|
struct object_id *oid = &iter2->item->object.oid;
|
|
|
|
|
entry = oidmap_get(&commit2todo, oid);
|
|
|
|
|
/* only show if not already upstream */
|
|
|
|
|
if (entry)
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addf(out, "%s\n", entry->string);
|
2018-04-25 20:29:03 +08:00
|
|
|
entry = oidmap_get(&state.commit2label, oid);
|
|
|
|
|
if (entry)
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addf(out, "%s %s\n",
|
|
|
|
|
cmd_label, entry->string);
|
2018-04-25 20:29:03 +08:00
|
|
|
oidset_insert(&shown, oid);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
free_commit_list(list);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
free_commit_list(commits);
|
|
|
|
|
free_commit_list(tips);
|
|
|
|
|
|
|
|
|
|
strbuf_release(&label);
|
|
|
|
|
strbuf_release(&oneline);
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
|
|
|
|
oidmap_free(&commit2todo, 1);
|
|
|
|
|
oidmap_free(&state.commit2label, 1);
|
|
|
|
|
hashmap_free(&state.labels, 1);
|
|
|
|
|
strbuf_release(&state.buf);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-06 03:17:56 +08:00
|
|
|
int sequencer_make_script(struct repository *r, struct strbuf *out, int argc,
|
|
|
|
|
const char **argv, unsigned flags)
|
2017-07-14 22:44:58 +08:00
|
|
|
{
|
|
|
|
|
char *format = NULL;
|
|
|
|
|
struct pretty_print_context pp = {0};
|
|
|
|
|
struct rev_info revs;
|
|
|
|
|
struct commit *commit;
|
2017-12-06 01:52:32 +08:00
|
|
|
int keep_empty = flags & TODO_LIST_KEEP_EMPTY;
|
2017-12-06 01:52:34 +08:00
|
|
|
const char *insn = flags & TODO_LIST_ABBREVIATE_CMDS ? "p" : "pick";
|
2018-04-25 20:29:03 +08:00
|
|
|
int rebase_merges = flags & TODO_LIST_REBASE_MERGES;
|
2017-07-14 22:44:58 +08:00
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
repo_init_revisions(r, &revs, NULL);
|
2017-07-14 22:44:58 +08:00
|
|
|
revs.verbose_header = 1;
|
2018-04-25 20:29:03 +08:00
|
|
|
if (!rebase_merges)
|
|
|
|
|
revs.max_parents = 1;
|
2018-03-20 18:03:14 +08:00
|
|
|
revs.cherry_mark = 1;
|
2017-07-14 22:44:58 +08:00
|
|
|
revs.limited = 1;
|
|
|
|
|
revs.reverse = 1;
|
|
|
|
|
revs.right_only = 1;
|
|
|
|
|
revs.sort_order = REV_SORT_IN_GRAPH_ORDER;
|
|
|
|
|
revs.topo_order = 1;
|
|
|
|
|
|
|
|
|
|
revs.pretty_given = 1;
|
|
|
|
|
git_config_get_string("rebase.instructionFormat", &format);
|
|
|
|
|
if (!format || !*format) {
|
|
|
|
|
free(format);
|
|
|
|
|
format = xstrdup("%s");
|
|
|
|
|
}
|
|
|
|
|
get_commit_format(format, &revs);
|
|
|
|
|
free(format);
|
|
|
|
|
pp.fmt = revs.commit_format;
|
|
|
|
|
pp.output_encoding = get_log_output_encoding();
|
|
|
|
|
|
|
|
|
|
if (setup_revisions(argc, argv, &revs, NULL) > 1)
|
|
|
|
|
return error(_("make_script: unhandled options"));
|
|
|
|
|
|
|
|
|
|
if (prepare_revision_walk(&revs) < 0)
|
|
|
|
|
return error(_("make_script: error preparing revisions"));
|
|
|
|
|
|
2018-04-25 20:29:03 +08:00
|
|
|
if (rebase_merges)
|
|
|
|
|
return make_script_with_merges(&pp, &revs, out, flags);
|
|
|
|
|
|
2017-07-14 22:44:58 +08:00
|
|
|
while ((commit = get_revision(&revs))) {
|
2018-03-20 18:03:14 +08:00
|
|
|
int is_empty = is_original_commit_empty(commit);
|
|
|
|
|
|
|
|
|
|
if (!is_empty && (commit->object.flags & PATCHSAME))
|
|
|
|
|
continue;
|
|
|
|
|
if (!keep_empty && is_empty)
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addf(out, "%c ", comment_line_char);
|
|
|
|
|
strbuf_addf(out, "%s %s ", insn,
|
2017-12-06 01:52:34 +08:00
|
|
|
oid_to_hex(&commit->object.oid));
|
2019-03-06 03:17:56 +08:00
|
|
|
pretty_print_commit(&pp, commit, out);
|
|
|
|
|
strbuf_addch(out, '\n');
|
2017-07-14 22:44:58 +08:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2017-07-14 22:45:11 +08:00
|
|
|
|
2017-12-06 01:52:33 +08:00
|
|
|
/*
|
|
|
|
|
* Add commands after pick and (series of) squash/fixup commands
|
|
|
|
|
* in the todo list.
|
|
|
|
|
*/
|
2019-03-06 03:17:58 +08:00
|
|
|
void todo_list_add_exec_commands(struct todo_list *todo_list,
|
|
|
|
|
struct string_list *commands)
|
2017-07-14 22:45:11 +08:00
|
|
|
{
|
2019-03-06 03:17:54 +08:00
|
|
|
struct strbuf *buf = &todo_list->buf;
|
|
|
|
|
size_t base_offset = buf->len;
|
|
|
|
|
int i, insert, nr = 0, alloc = 0;
|
|
|
|
|
struct todo_item *items = NULL, *base_items = NULL;
|
2017-07-14 22:45:11 +08:00
|
|
|
|
2019-03-06 03:17:54 +08:00
|
|
|
base_items = xcalloc(commands->nr, sizeof(struct todo_item));
|
|
|
|
|
for (i = 0; i < commands->nr; i++) {
|
|
|
|
|
size_t command_len = strlen(commands->items[i].string);
|
2017-07-14 22:45:11 +08:00
|
|
|
|
2019-03-06 03:17:54 +08:00
|
|
|
strbuf_addstr(buf, commands->items[i].string);
|
|
|
|
|
strbuf_addch(buf, '\n');
|
2017-07-14 22:45:11 +08:00
|
|
|
|
2019-03-06 03:17:54 +08:00
|
|
|
base_items[i].command = TODO_EXEC;
|
|
|
|
|
base_items[i].offset_in_buf = base_offset;
|
|
|
|
|
base_items[i].arg_offset = base_offset + strlen("exec ");
|
|
|
|
|
base_items[i].arg_len = command_len - strlen("exec ");
|
2017-07-14 22:45:11 +08:00
|
|
|
|
2019-03-06 03:17:54 +08:00
|
|
|
base_offset += command_len + 1;
|
2017-07-14 22:45:11 +08:00
|
|
|
}
|
|
|
|
|
|
rebase --exec: make it work with --rebase-merges
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of its corresponding
`fixup` or `squash` lines.
The current implementation uses a dirty trick to achieve that: it
assumes that there are only pick/fixup/squash commands, and then
*inserts* the `exec` lines before any `pick` but the first, and appends
a final one.
With the todo lists generated by `git rebase --rebase-merges`, this
simple implementation shows its problems: it produces the exact wrong
thing when there are `label`, `reset` and `merge` commands.
Let's change the implementation to do exactly what we want: look for
`pick` lines, skip any fixup/squash chains, and then insert the `exec`
line. Lather, rinse, repeat.
Note: we take pains to insert *before* comment lines whenever possible,
as empty commits are represented by commented-out pick lines (and we
want to insert a preceding pick's exec line *before* such a line, not
afterward).
While at it, also add `exec` lines after `merge` commands, because they
are similar in spirit to `pick` commands: they add new commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-09 17:41:11 +08:00
|
|
|
/*
|
|
|
|
|
* Insert <commands> after every pick. Here, fixup/squash chains
|
|
|
|
|
* are considered part of the pick, so we insert the commands *after*
|
|
|
|
|
* those chains if there are any.
|
2019-03-06 03:17:54 +08:00
|
|
|
*
|
|
|
|
|
* As we insert the exec commands immediatly after rearranging
|
|
|
|
|
* any fixups and before the user edits the list, a fixup chain
|
|
|
|
|
* can never contain comments (any comments are empty picks that
|
|
|
|
|
* have been commented out because the user did not specify
|
|
|
|
|
* --keep-empty). So, it is safe to insert an exec command
|
|
|
|
|
* without looking at the command following a comment.
|
rebase --exec: make it work with --rebase-merges
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of its corresponding
`fixup` or `squash` lines.
The current implementation uses a dirty trick to achieve that: it
assumes that there are only pick/fixup/squash commands, and then
*inserts* the `exec` lines before any `pick` but the first, and appends
a final one.
With the todo lists generated by `git rebase --rebase-merges`, this
simple implementation shows its problems: it produces the exact wrong
thing when there are `label`, `reset` and `merge` commands.
Let's change the implementation to do exactly what we want: look for
`pick` lines, skip any fixup/squash chains, and then insert the `exec`
line. Lather, rinse, repeat.
Note: we take pains to insert *before* comment lines whenever possible,
as empty commits are represented by commented-out pick lines (and we
want to insert a preceding pick's exec line *before* such a line, not
afterward).
While at it, also add `exec` lines after `merge` commands, because they
are similar in spirit to `pick` commands: they add new commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-09 17:41:11 +08:00
|
|
|
*/
|
2019-03-06 03:17:54 +08:00
|
|
|
insert = 0;
|
|
|
|
|
for (i = 0; i < todo_list->nr; i++) {
|
|
|
|
|
enum todo_command command = todo_list->items[i].command;
|
|
|
|
|
if (insert && !is_fixup(command)) {
|
|
|
|
|
ALLOC_GROW(items, nr + commands->nr, alloc);
|
|
|
|
|
COPY_ARRAY(items + nr, base_items, commands->nr);
|
|
|
|
|
nr += commands->nr;
|
|
|
|
|
|
|
|
|
|
insert = 0;
|
2017-12-06 01:52:33 +08:00
|
|
|
}
|
rebase --exec: make it work with --rebase-merges
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of its corresponding
`fixup` or `squash` lines.
The current implementation uses a dirty trick to achieve that: it
assumes that there are only pick/fixup/squash commands, and then
*inserts* the `exec` lines before any `pick` but the first, and appends
a final one.
With the todo lists generated by `git rebase --rebase-merges`, this
simple implementation shows its problems: it produces the exact wrong
thing when there are `label`, `reset` and `merge` commands.
Let's change the implementation to do exactly what we want: look for
`pick` lines, skip any fixup/squash chains, and then insert the `exec`
line. Lather, rinse, repeat.
Note: we take pains to insert *before* comment lines whenever possible,
as empty commits are represented by commented-out pick lines (and we
want to insert a preceding pick's exec line *before* such a line, not
afterward).
While at it, also add `exec` lines after `merge` commands, because they
are similar in spirit to `pick` commands: they add new commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-09 17:41:11 +08:00
|
|
|
|
2019-03-06 03:17:54 +08:00
|
|
|
ALLOC_GROW(items, nr + 1, alloc);
|
|
|
|
|
items[nr++] = todo_list->items[i];
|
|
|
|
|
|
rebase --exec: make it work with --rebase-merges
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of its corresponding
`fixup` or `squash` lines.
The current implementation uses a dirty trick to achieve that: it
assumes that there are only pick/fixup/squash commands, and then
*inserts* the `exec` lines before any `pick` but the first, and appends
a final one.
With the todo lists generated by `git rebase --rebase-merges`, this
simple implementation shows its problems: it produces the exact wrong
thing when there are `label`, `reset` and `merge` commands.
Let's change the implementation to do exactly what we want: look for
`pick` lines, skip any fixup/squash chains, and then insert the `exec`
line. Lather, rinse, repeat.
Note: we take pains to insert *before* comment lines whenever possible,
as empty commits are represented by commented-out pick lines (and we
want to insert a preceding pick's exec line *before* such a line, not
afterward).
While at it, also add `exec` lines after `merge` commands, because they
are similar in spirit to `pick` commands: they add new commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-09 17:41:11 +08:00
|
|
|
if (command == TODO_PICK || command == TODO_MERGE)
|
2019-03-06 03:17:54 +08:00
|
|
|
insert = 1;
|
2017-12-06 01:52:33 +08:00
|
|
|
}
|
|
|
|
|
|
rebase --exec: make it work with --rebase-merges
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of its corresponding
`fixup` or `squash` lines.
The current implementation uses a dirty trick to achieve that: it
assumes that there are only pick/fixup/squash commands, and then
*inserts* the `exec` lines before any `pick` but the first, and appends
a final one.
With the todo lists generated by `git rebase --rebase-merges`, this
simple implementation shows its problems: it produces the exact wrong
thing when there are `label`, `reset` and `merge` commands.
Let's change the implementation to do exactly what we want: look for
`pick` lines, skip any fixup/squash chains, and then insert the `exec`
line. Lather, rinse, repeat.
Note: we take pains to insert *before* comment lines whenever possible,
as empty commits are represented by commented-out pick lines (and we
want to insert a preceding pick's exec line *before* such a line, not
afterward).
While at it, also add `exec` lines after `merge` commands, because they
are similar in spirit to `pick` commands: they add new commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-09 17:41:11 +08:00
|
|
|
/* insert or append final <commands> */
|
2019-03-06 03:17:54 +08:00
|
|
|
if (insert || nr == todo_list->nr) {
|
|
|
|
|
ALLOC_GROW(items, nr + commands->nr, alloc);
|
|
|
|
|
COPY_ARRAY(items + nr, base_items, commands->nr);
|
|
|
|
|
nr += commands->nr;
|
|
|
|
|
}
|
2017-12-06 01:52:33 +08:00
|
|
|
|
2019-03-06 03:17:54 +08:00
|
|
|
free(base_items);
|
|
|
|
|
FREE_AND_NULL(todo_list->items);
|
|
|
|
|
todo_list->items = items;
|
|
|
|
|
todo_list->nr = nr;
|
|
|
|
|
todo_list->alloc = alloc;
|
2017-12-06 01:52:33 +08:00
|
|
|
}
|
2017-07-14 22:45:11 +08:00
|
|
|
|
2019-01-29 23:01:48 +08:00
|
|
|
static void todo_list_to_strbuf(struct repository *r, struct todo_list *todo_list,
|
|
|
|
|
struct strbuf *buf, int num, unsigned flags)
|
2017-07-14 22:45:11 +08:00
|
|
|
{
|
2017-12-06 01:52:30 +08:00
|
|
|
struct todo_item *item;
|
2019-01-29 23:01:48 +08:00
|
|
|
int i, max = todo_list->nr;
|
2017-07-14 22:45:11 +08:00
|
|
|
|
2019-01-29 23:01:48 +08:00
|
|
|
if (num > 0 && num < max)
|
|
|
|
|
max = num;
|
2017-07-14 22:45:11 +08:00
|
|
|
|
2019-01-29 23:01:48 +08:00
|
|
|
for (item = todo_list->items, i = 0; i < max; i++, item++) {
|
2017-12-06 01:52:30 +08:00
|
|
|
/* if the item is not a command write it and continue */
|
|
|
|
|
if (item->command >= TODO_COMMENT) {
|
2019-01-29 23:01:48 +08:00
|
|
|
strbuf_addf(buf, "%.*s\n", item->arg_len,
|
2019-01-29 23:01:47 +08:00
|
|
|
todo_item_get_arg(todo_list, item));
|
2017-12-06 01:52:30 +08:00
|
|
|
continue;
|
2017-07-14 22:45:11 +08:00
|
|
|
}
|
2017-12-06 01:52:30 +08:00
|
|
|
|
|
|
|
|
/* add command to the buffer */
|
2017-12-06 01:52:34 +08:00
|
|
|
if (flags & TODO_LIST_ABBREVIATE_CMDS)
|
2019-01-29 23:01:48 +08:00
|
|
|
strbuf_addch(buf, command_to_char(item->command));
|
2017-12-06 01:52:34 +08:00
|
|
|
else
|
2019-01-29 23:01:48 +08:00
|
|
|
strbuf_addstr(buf, command_to_string(item->command));
|
2017-12-06 01:52:30 +08:00
|
|
|
|
|
|
|
|
/* add commit id */
|
|
|
|
|
if (item->commit) {
|
2017-12-06 01:52:32 +08:00
|
|
|
const char *oid = flags & TODO_LIST_SHORTEN_IDS ?
|
2017-12-06 01:52:30 +08:00
|
|
|
short_commit_name(item->commit) :
|
|
|
|
|
oid_to_hex(&item->commit->object.oid);
|
|
|
|
|
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
if (item->command == TODO_MERGE) {
|
|
|
|
|
if (item->flags & TODO_EDIT_MERGE_MSG)
|
2019-01-29 23:01:48 +08:00
|
|
|
strbuf_addstr(buf, " -c");
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
else
|
2019-01-29 23:01:48 +08:00
|
|
|
strbuf_addstr(buf, " -C");
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
}
|
|
|
|
|
|
2019-01-29 23:01:48 +08:00
|
|
|
strbuf_addf(buf, " %s", oid);
|
2017-07-14 22:45:11 +08:00
|
|
|
}
|
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `reset` commands to label
commits and to reset to labeled commits. This patch adds the `merge`
command, with the following syntax:
merge [-C <commit>] <rev> # <oneline>
The <commit> parameter in this instance is the *original* merge commit,
whose author and message will be used for the merge commit that is about
to be created.
The <rev> parameter refers to the (possibly rewritten) revision to
merge. Let's see an example of a todo list (the initial `label onto`
command is an auto-generated convenience so that the label `onto` can be
used to refer to the revision onto which we rebase):
label onto
# Branch abc
reset onto
pick deadbeef Hello, world!
label abc
reset onto
pick cafecafe And now for something completely different
merge -C baaabaaa abc # Merge the branch 'abc' into master
To edit the merge commit's message (a "reword" for merges, if you will),
use `-c` (lower-case) instead of `-C`; this convention was borrowed from
`git commit` that also supports `-c` and `-C` with similar meanings.
To create *new* merges, i.e. without copying the commit message from an
existing commit, simply omit the `-C <commit>` parameter (which will
open an editor for the merge message):
merge abc
This comes in handy when splitting a branch into two or more branches.
Note: this patch only adds support for recursive merges, to keep things
simple. Support for octopus merges will be added later in a separate
patch series, support for merges using strategies other than the
recursive merge is left for the future.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 20:28:54 +08:00
|
|
|
|
2017-12-06 01:52:30 +08:00
|
|
|
/* add all the rest */
|
2017-12-23 07:56:00 +08:00
|
|
|
if (!item->arg_len)
|
2019-01-29 23:01:48 +08:00
|
|
|
strbuf_addch(buf, '\n');
|
2017-12-23 07:56:00 +08:00
|
|
|
else
|
2019-01-29 23:01:48 +08:00
|
|
|
strbuf_addf(buf, " %.*s\n", item->arg_len,
|
2019-01-29 23:01:47 +08:00
|
|
|
todo_item_get_arg(todo_list, item));
|
2017-07-14 22:45:11 +08:00
|
|
|
}
|
|
|
|
|
}
|
2017-07-14 22:45:21 +08:00
|
|
|
|
2019-01-29 23:01:48 +08:00
|
|
|
int todo_list_write_to_file(struct repository *r, struct todo_list *todo_list,
|
|
|
|
|
const char *file, const char *shortrevisions,
|
|
|
|
|
const char *shortonto, int num, unsigned flags)
|
2017-07-14 22:45:21 +08:00
|
|
|
{
|
2019-03-06 03:18:02 +08:00
|
|
|
int res;
|
2019-01-29 23:01:48 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2017-07-14 22:45:21 +08:00
|
|
|
|
2019-01-29 23:01:48 +08:00
|
|
|
todo_list_to_strbuf(r, todo_list, &buf, num, flags);
|
2019-03-06 03:18:02 +08:00
|
|
|
if (flags & TODO_LIST_APPEND_TODO_HELP)
|
|
|
|
|
append_todo_help(flags & TODO_LIST_KEEP_EMPTY, count_commands(todo_list),
|
|
|
|
|
shortrevisions, shortonto, &buf);
|
2017-07-14 22:45:21 +08:00
|
|
|
|
2019-01-29 23:01:48 +08:00
|
|
|
res = write_message(buf.buf, buf.len, file, 0);
|
2019-01-29 23:01:47 +08:00
|
|
|
strbuf_release(&buf);
|
2018-05-19 13:28:22 +08:00
|
|
|
|
2019-01-29 23:01:48 +08:00
|
|
|
return res;
|
2019-01-29 23:01:47 +08:00
|
|
|
}
|
2017-07-14 22:45:21 +08:00
|
|
|
|
2019-01-29 23:01:49 +08:00
|
|
|
static const char edit_todo_list_advice[] =
|
|
|
|
|
N_("You can fix this with 'git rebase --edit-todo' "
|
|
|
|
|
"and then run 'git rebase --continue'.\n"
|
|
|
|
|
"Or you can abort the rebase with 'git rebase"
|
|
|
|
|
" --abort'.\n");
|
2017-07-14 22:45:21 +08:00
|
|
|
|
2019-01-29 23:01:49 +08:00
|
|
|
int check_todo_list_from_file(struct repository *r)
|
2017-07-14 22:45:21 +08:00
|
|
|
{
|
2019-01-29 23:01:49 +08:00
|
|
|
struct todo_list old_todo = TODO_LIST_INIT, new_todo = TODO_LIST_INIT;
|
|
|
|
|
int res = 0;
|
2017-07-14 22:45:21 +08:00
|
|
|
|
2019-01-29 23:01:49 +08:00
|
|
|
if (strbuf_read_file_or_whine(&new_todo.buf, rebase_path_todo()) < 0) {
|
2018-02-23 03:29:25 +08:00
|
|
|
res = -1;
|
2019-01-29 23:01:49 +08:00
|
|
|
goto out;
|
2017-07-14 22:45:21 +08:00
|
|
|
}
|
|
|
|
|
|
2019-01-29 23:01:49 +08:00
|
|
|
if (strbuf_read_file_or_whine(&old_todo.buf, rebase_path_todo_backup()) < 0) {
|
2018-02-23 03:29:25 +08:00
|
|
|
res = -1;
|
2019-01-29 23:01:49 +08:00
|
|
|
goto out;
|
2017-07-14 22:45:21 +08:00
|
|
|
}
|
|
|
|
|
|
2019-01-29 23:01:49 +08:00
|
|
|
res = todo_list_parse_insn_buffer(r, old_todo.buf.buf, &old_todo);
|
|
|
|
|
if (!res)
|
|
|
|
|
res = todo_list_parse_insn_buffer(r, new_todo.buf.buf, &new_todo);
|
|
|
|
|
if (!res)
|
|
|
|
|
res = todo_list_check(&old_todo, &new_todo);
|
|
|
|
|
if (res)
|
|
|
|
|
fprintf(stderr, _(edit_todo_list_advice));
|
|
|
|
|
out:
|
|
|
|
|
todo_list_release(&old_todo);
|
|
|
|
|
todo_list_release(&new_todo);
|
2017-07-14 22:45:21 +08:00
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|
2017-07-14 22:45:25 +08:00
|
|
|
|
|
|
|
|
/* skip picking commits whose parents are unchanged */
|
2019-03-06 03:18:00 +08:00
|
|
|
static int skip_unnecessary_picks(struct repository *r,
|
|
|
|
|
struct todo_list *todo_list,
|
|
|
|
|
struct object_id *base_oid)
|
2017-07-14 22:45:25 +08:00
|
|
|
{
|
2018-08-11 00:51:36 +08:00
|
|
|
struct object_id *parent_oid;
|
2019-03-06 03:18:00 +08:00
|
|
|
int i;
|
2017-07-14 22:45:25 +08:00
|
|
|
|
2019-03-06 03:18:00 +08:00
|
|
|
for (i = 0; i < todo_list->nr; i++) {
|
|
|
|
|
struct todo_item *item = todo_list->items + i;
|
2017-07-14 22:45:25 +08:00
|
|
|
|
|
|
|
|
if (item->command >= TODO_NOOP)
|
|
|
|
|
continue;
|
|
|
|
|
if (item->command != TODO_PICK)
|
|
|
|
|
break;
|
|
|
|
|
if (parse_commit(item->commit)) {
|
|
|
|
|
return error(_("could not parse commit '%s'"),
|
|
|
|
|
oid_to_hex(&item->commit->object.oid));
|
|
|
|
|
}
|
|
|
|
|
if (!item->commit->parents)
|
|
|
|
|
break; /* root commit */
|
|
|
|
|
if (item->commit->parents->next)
|
|
|
|
|
break; /* merge commit */
|
|
|
|
|
parent_oid = &item->commit->parents->item->object.oid;
|
2019-03-06 03:18:00 +08:00
|
|
|
if (!oideq(parent_oid, base_oid))
|
2017-07-14 22:45:25 +08:00
|
|
|
break;
|
2019-03-06 03:18:00 +08:00
|
|
|
oidcpy(base_oid, &item->commit->object.oid);
|
2017-07-14 22:45:25 +08:00
|
|
|
}
|
|
|
|
|
if (i > 0) {
|
|
|
|
|
const char *done_path = rebase_path_done();
|
|
|
|
|
|
2019-03-06 03:18:00 +08:00
|
|
|
if (todo_list_write_to_file(r, todo_list, done_path, NULL, NULL, i, 0)) {
|
2017-07-14 22:45:25 +08:00
|
|
|
error_errno(_("could not write to '%s'"), done_path);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-06 03:18:00 +08:00
|
|
|
MOVE_ARRAY(todo_list->items, todo_list->items + i, todo_list->nr - i);
|
|
|
|
|
todo_list->nr -= i;
|
|
|
|
|
todo_list->current = 0;
|
2017-07-14 22:45:25 +08:00
|
|
|
|
2019-03-06 03:18:00 +08:00
|
|
|
if (is_fixup(peek_command(todo_list, 0)))
|
|
|
|
|
record_in_rewritten(base_oid, peek_command(todo_list, 0));
|
2017-07-14 22:45:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2017-07-14 22:45:31 +08:00
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
int complete_action(struct repository *r, struct replay_opts *opts, unsigned flags,
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
const char *shortrevisions, const char *onto_name,
|
2019-04-17 22:30:39 +08:00
|
|
|
struct commit *onto, const char *orig_head,
|
|
|
|
|
struct string_list *commands, unsigned autosquash,
|
|
|
|
|
struct todo_list *todo_list)
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
{
|
|
|
|
|
const char *shortonto, *todo_file = rebase_path_todo();
|
2019-03-06 03:17:57 +08:00
|
|
|
struct todo_list new_todo = TODO_LIST_INIT;
|
|
|
|
|
struct strbuf *buf = &todo_list->buf;
|
2019-04-17 22:30:39 +08:00
|
|
|
struct object_id oid = onto->object.oid;
|
2019-03-06 03:18:04 +08:00
|
|
|
int res;
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
|
|
|
|
|
shortonto = find_unique_abbrev(&oid, DEFAULT_ABBREV);
|
|
|
|
|
|
2019-03-06 03:17:57 +08:00
|
|
|
if (buf->len == 0) {
|
|
|
|
|
struct todo_item *item = append_new_todo(todo_list);
|
|
|
|
|
item->command = TODO_NOOP;
|
|
|
|
|
item->commit = NULL;
|
|
|
|
|
item->arg_len = item->arg_offset = item->flags = item->offset_in_buf = 0;
|
|
|
|
|
}
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
|
2019-03-06 03:17:57 +08:00
|
|
|
if (autosquash && todo_list_rearrange_squash(todo_list))
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
return -1;
|
|
|
|
|
|
2019-03-06 03:17:54 +08:00
|
|
|
if (commands->nr)
|
2019-03-06 03:17:57 +08:00
|
|
|
todo_list_add_exec_commands(todo_list, commands);
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
|
2019-03-06 03:17:57 +08:00
|
|
|
if (count_commands(todo_list) == 0) {
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
apply_autostash(opts);
|
|
|
|
|
sequencer_remove_state(opts);
|
|
|
|
|
|
|
|
|
|
return error(_("nothing to do"));
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-06 03:18:04 +08:00
|
|
|
res = edit_todo_list(r, todo_list, &new_todo, shortrevisions,
|
|
|
|
|
shortonto, flags);
|
|
|
|
|
if (res == -1)
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
return -1;
|
2019-03-06 03:18:04 +08:00
|
|
|
else if (res == -2) {
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
apply_autostash(opts);
|
|
|
|
|
sequencer_remove_state(opts);
|
|
|
|
|
|
|
|
|
|
return -1;
|
2019-03-06 03:18:04 +08:00
|
|
|
} else if (res == -3) {
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
apply_autostash(opts);
|
|
|
|
|
sequencer_remove_state(opts);
|
2019-03-06 03:17:57 +08:00
|
|
|
todo_list_release(&new_todo);
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
|
|
|
|
|
return error(_("nothing to do"));
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-06 03:17:57 +08:00
|
|
|
if (todo_list_parse_insn_buffer(r, new_todo.buf.buf, &new_todo) ||
|
|
|
|
|
todo_list_check(todo_list, &new_todo)) {
|
|
|
|
|
fprintf(stderr, _(edit_todo_list_advice));
|
2019-04-17 22:30:39 +08:00
|
|
|
checkout_onto(r, opts, onto_name, &onto->object.oid, orig_head);
|
2019-03-06 03:17:57 +08:00
|
|
|
todo_list_release(&new_todo);
|
|
|
|
|
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-06 03:18:00 +08:00
|
|
|
if (opts->allow_ff && skip_unnecessary_picks(r, &new_todo, &oid)) {
|
|
|
|
|
todo_list_release(&new_todo);
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
return error(_("could not skip unnecessary pick commands"));
|
2019-03-06 03:18:00 +08:00
|
|
|
}
|
|
|
|
|
|
2019-03-06 03:17:57 +08:00
|
|
|
if (todo_list_write_to_file(r, &new_todo, todo_file, NULL, NULL, -1,
|
|
|
|
|
flags & ~(TODO_LIST_SHORTEN_IDS))) {
|
|
|
|
|
todo_list_release(&new_todo);
|
|
|
|
|
return error_errno(_("could not write '%s'"), todo_file);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
todo_list_release(&new_todo);
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
|
2019-04-17 22:30:39 +08:00
|
|
|
if (checkout_onto(r, opts, onto_name, &oid, orig_head))
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
return -1;
|
2018-11-03 22:32:29 +08:00
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
if (require_clean_work_tree(r, "rebase", "", 1, 1))
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
return -1;
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
return sequencer_continue(r, opts);
|
rebase -i: rewrite complete_action() in C
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list contained no actions. This was a special case for rebase -i and
-p; git-rebase.sh would then apply the autostash, delete the state
directory, and die with the message "Nothing to do". This cleanup is
rewritten in C instead of returning 2. As rebase -i no longer returns
2, the comment describing this behaviour in git-rebase.sh is updated to
reflect this change.
The message "Nothing to do" is now printed with error(), and so becomes
"error: nothing to do". Some tests in t3404 check this value, so they
are updated to fit this change.
The first check might seem useless as we write "noop" to the todo list
if it is empty. Actually, the todo list might contain commented
commands (ie. empty commits). In this case, complete_action() won’t
write "noop", and will abort without starting the editor.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 20:10:36 +08:00
|
|
|
}
|
|
|
|
|
|
2017-07-14 22:45:31 +08:00
|
|
|
struct subject2item_entry {
|
|
|
|
|
struct hashmap_entry entry;
|
|
|
|
|
int i;
|
|
|
|
|
char subject[FLEX_ARRAY];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int subject2item_cmp(const void *fndata,
|
|
|
|
|
const struct subject2item_entry *a,
|
|
|
|
|
const struct subject2item_entry *b, const void *key)
|
|
|
|
|
{
|
|
|
|
|
return key ? strcmp(a->subject, key) : strcmp(a->subject, b->subject);
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-19 13:28:23 +08:00
|
|
|
define_commit_slab(commit_todo_item, struct todo_item *);
|
|
|
|
|
|
2017-07-14 22:45:31 +08:00
|
|
|
/*
|
|
|
|
|
* Rearrange the todo list that has both "pick commit-id msg" and "pick
|
|
|
|
|
* commit-id fixup!/squash! msg" in it so that the latter is put immediately
|
|
|
|
|
* after the former, and change "pick" to "fixup"/"squash".
|
|
|
|
|
*
|
|
|
|
|
* Note that if the config has specified a custom instruction format, each log
|
|
|
|
|
* message will have to be retrieved from the commit (as the oneline in the
|
|
|
|
|
* script cannot be trusted) in order to normalize the autosquash arrangement.
|
|
|
|
|
*/
|
2019-03-06 03:17:59 +08:00
|
|
|
int todo_list_rearrange_squash(struct todo_list *todo_list)
|
2017-07-14 22:45:31 +08:00
|
|
|
{
|
|
|
|
|
struct hashmap subject2item;
|
2019-03-06 03:17:55 +08:00
|
|
|
int rearranged = 0, *next, *tail, i, nr = 0, alloc = 0;
|
2017-07-14 22:45:31 +08:00
|
|
|
char **subjects;
|
2018-05-19 13:28:23 +08:00
|
|
|
struct commit_todo_item commit_todo;
|
2019-03-06 03:17:55 +08:00
|
|
|
struct todo_item *items = NULL;
|
2017-07-14 22:45:31 +08:00
|
|
|
|
2018-05-19 13:28:23 +08:00
|
|
|
init_commit_todo_item(&commit_todo);
|
2017-07-14 22:45:31 +08:00
|
|
|
/*
|
|
|
|
|
* The hashmap maps onelines to the respective todo list index.
|
|
|
|
|
*
|
|
|
|
|
* If any items need to be rearranged, the next[i] value will indicate
|
|
|
|
|
* which item was moved directly after the i'th.
|
|
|
|
|
*
|
|
|
|
|
* In that case, last[i] will indicate the index of the latest item to
|
|
|
|
|
* be moved to appear after the i'th.
|
|
|
|
|
*/
|
|
|
|
|
hashmap_init(&subject2item, (hashmap_cmp_fn) subject2item_cmp,
|
2019-03-06 03:17:55 +08:00
|
|
|
NULL, todo_list->nr);
|
|
|
|
|
ALLOC_ARRAY(next, todo_list->nr);
|
|
|
|
|
ALLOC_ARRAY(tail, todo_list->nr);
|
|
|
|
|
ALLOC_ARRAY(subjects, todo_list->nr);
|
|
|
|
|
for (i = 0; i < todo_list->nr; i++) {
|
2017-07-14 22:45:31 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2019-03-06 03:17:55 +08:00
|
|
|
struct todo_item *item = todo_list->items + i;
|
2017-07-14 22:45:31 +08:00
|
|
|
const char *commit_buffer, *subject, *p;
|
|
|
|
|
size_t subject_len;
|
|
|
|
|
int i2 = -1;
|
|
|
|
|
struct subject2item_entry *entry;
|
|
|
|
|
|
|
|
|
|
next[i] = tail[i] = -1;
|
2018-04-25 20:28:25 +08:00
|
|
|
if (!item->commit || item->command == TODO_DROP) {
|
2017-07-14 22:45:31 +08:00
|
|
|
subjects[i] = NULL;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (is_fixup(item->command)) {
|
2018-05-19 13:28:23 +08:00
|
|
|
clear_commit_todo_item(&commit_todo);
|
2017-07-14 22:45:31 +08:00
|
|
|
return error(_("the script was already rearranged."));
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-19 13:28:23 +08:00
|
|
|
*commit_todo_item_at(&commit_todo, item->commit) = item;
|
2017-07-14 22:45:31 +08:00
|
|
|
|
|
|
|
|
parse_commit(item->commit);
|
|
|
|
|
commit_buffer = get_commit_buffer(item->commit, NULL);
|
|
|
|
|
find_commit_subject(commit_buffer, &subject);
|
|
|
|
|
format_subject(&buf, subject, " ");
|
|
|
|
|
subject = subjects[i] = strbuf_detach(&buf, &subject_len);
|
|
|
|
|
unuse_commit_buffer(item->commit, commit_buffer);
|
|
|
|
|
if ((skip_prefix(subject, "fixup! ", &p) ||
|
|
|
|
|
skip_prefix(subject, "squash! ", &p))) {
|
|
|
|
|
struct commit *commit2;
|
|
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
while (isspace(*p))
|
|
|
|
|
p++;
|
|
|
|
|
if (!skip_prefix(p, "fixup! ", &p) &&
|
|
|
|
|
!skip_prefix(p, "squash! ", &p))
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ((entry = hashmap_get_from_hash(&subject2item,
|
|
|
|
|
strhash(p), p)))
|
|
|
|
|
/* found by title */
|
|
|
|
|
i2 = entry->i;
|
|
|
|
|
else if (!strchr(p, ' ') &&
|
|
|
|
|
(commit2 =
|
|
|
|
|
lookup_commit_reference_by_name(p)) &&
|
2018-05-19 13:28:23 +08:00
|
|
|
*commit_todo_item_at(&commit_todo, commit2))
|
2017-07-14 22:45:31 +08:00
|
|
|
/* found by commit name */
|
2018-05-19 13:28:23 +08:00
|
|
|
i2 = *commit_todo_item_at(&commit_todo, commit2)
|
2019-03-06 03:17:55 +08:00
|
|
|
- todo_list->items;
|
2017-07-14 22:45:31 +08:00
|
|
|
else {
|
|
|
|
|
/* copy can be a prefix of the commit subject */
|
|
|
|
|
for (i2 = 0; i2 < i; i2++)
|
|
|
|
|
if (subjects[i2] &&
|
|
|
|
|
starts_with(subjects[i2], p))
|
|
|
|
|
break;
|
|
|
|
|
if (i2 == i)
|
|
|
|
|
i2 = -1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (i2 >= 0) {
|
|
|
|
|
rearranged = 1;
|
2019-03-06 03:17:55 +08:00
|
|
|
todo_list->items[i].command =
|
2017-07-14 22:45:31 +08:00
|
|
|
starts_with(subject, "fixup!") ?
|
|
|
|
|
TODO_FIXUP : TODO_SQUASH;
|
|
|
|
|
if (next[i2] < 0)
|
|
|
|
|
next[i2] = i;
|
|
|
|
|
else
|
|
|
|
|
next[tail[i2]] = i;
|
|
|
|
|
tail[i2] = i;
|
|
|
|
|
} else if (!hashmap_get_from_hash(&subject2item,
|
|
|
|
|
strhash(subject), subject)) {
|
|
|
|
|
FLEX_ALLOC_MEM(entry, subject, subject, subject_len);
|
|
|
|
|
entry->i = i;
|
|
|
|
|
hashmap_entry_init(entry, strhash(entry->subject));
|
|
|
|
|
hashmap_put(&subject2item, entry);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (rearranged) {
|
2019-03-06 03:17:55 +08:00
|
|
|
for (i = 0; i < todo_list->nr; i++) {
|
|
|
|
|
enum todo_command command = todo_list->items[i].command;
|
2017-07-14 22:45:31 +08:00
|
|
|
int cur = i;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Initially, all commands are 'pick's. If it is a
|
|
|
|
|
* fixup or a squash now, we have rearranged it.
|
|
|
|
|
*/
|
|
|
|
|
if (is_fixup(command))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
while (cur >= 0) {
|
2019-03-06 03:17:55 +08:00
|
|
|
ALLOC_GROW(items, nr + 1, alloc);
|
|
|
|
|
items[nr++] = todo_list->items[cur];
|
2017-07-14 22:45:31 +08:00
|
|
|
cur = next[cur];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-06 03:17:55 +08:00
|
|
|
FREE_AND_NULL(todo_list->items);
|
|
|
|
|
todo_list->items = items;
|
|
|
|
|
todo_list->nr = nr;
|
|
|
|
|
todo_list->alloc = alloc;
|
2017-07-14 22:45:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
free(next);
|
|
|
|
|
free(tail);
|
2019-03-06 03:17:55 +08:00
|
|
|
for (i = 0; i < todo_list->nr; i++)
|
2017-07-14 22:45:31 +08:00
|
|
|
free(subjects[i]);
|
|
|
|
|
free(subjects);
|
|
|
|
|
hashmap_free(&subject2item, 1);
|
|
|
|
|
|
2018-05-19 13:28:23 +08:00
|
|
|
clear_commit_todo_item(&commit_todo);
|
2019-03-06 03:17:55 +08:00
|
|
|
|
|
|
|
|
return 0;
|
2017-07-14 22:45:31 +08:00
|
|
|
}
|
