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"
|
2021-09-27 03:03:26 +08:00
|
|
|
#include "hook.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"
|
2020-11-03 07:45:34 +08:00
|
|
|
#include "merge-ort.h"
|
|
|
|
|
#include "merge-ort-wrappers.h"
|
2012-01-12 02:15:57 +08:00
|
|
|
#include "refs.h"
|
2020-07-29 04:23:39 +08:00
|
|
|
#include "strvec.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"
|
2020-04-07 22:28:03 +08:00
|
|
|
#include "reset.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")
|
|
|
|
|
|
2019-12-07 00:06:11 +08:00
|
|
|
static GIT_PATH_FUNC(git_path_seq_dir, "sequencer")
|
2016-10-14 21:17:12 +08:00
|
|
|
|
|
|
|
|
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
|
|
|
|
rebase-interactive: warn if commit is dropped with `rebase --edit-todo'
When set to "warn" or "error", `rebase.missingCommitsCheck' would make
`rebase -i' warn if the user removed commits from the todo list to
prevent mistakes. Unfortunately, `rebase --edit-todo' and `rebase
--continue' don't take it into account.
This adds the ability for `rebase --edit-todo' and `rebase --continue'
to check if commits were dropped by the user. As both edit_todo_list()
and complete_action() parse the todo list and check for dropped commits,
the code doing so in the latter is removed to reduce duplication.
`edit_todo_list_advice' is removed from sequencer.c as it is no longer
used there.
This changes when a backup of the todo list is made. Until now, it was
saved only once, before the initial edit. Now, it is also made if the
original todo list has no errors or no dropped commits. Thus, the
backup should be error-free. Without this, sequencer_continue()
(`rebase --continue') could only compare the current todo list against
the original, unedited list. Before this change, this file was only
used by edit_todo_list() and `rebase -p' to create the backup before
the initial edit, and check_todo_list_from_file(), only used by
`rebase -p' to check for dropped commits after its own initial edit.
If the edited list has an error, a file, `dropped', is created to
report the issue. Otherwise, it is deleted. Usually, the edited list
is compared against the list before editing, but if this file exists,
it will be compared to the backup. Also, if the file exists,
sequencer_continue() checks the list for dropped commits. If the
check was performed every time, it would fail when resuming a rebase
after resolving a conflict, as the backup will contain commits that
were picked, but they will not be in the new list. It's safe to
ignore this check if `dropped' does not exist, because that means that
no errors were found at the last edition, so any missing commits here
have already been picked.
Five tests are added to t3404. The tests for
`rebase.missingCommitsCheck = warn' and `rebase.missingCommitsCheck =
error' have a similar structure. First, we start a rebase with an
incorrect command on the first line. Then, we edit the todo list,
removing the first and the last lines. This demonstrates that
`--edit-todo' notices dropped commits, but not when the command is
incorrect. Then, we restore the original todo list, and edit it to
remove the last line. This demonstrates that if we add a commit after
the initial edit, then remove it, `--edit-todo' will notice that it
has been dropped. Then, the actual rebase takes place. In the third
test, it is also checked that `--continue' will refuse to resume the
rebase if commits were dropped. The fourth test checks that no errors
are raised when resuming a rebase after resolving a conflict, the fifth
checks that no errors are raised when editing the todo list after
pausing the rebase.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-29 05:12:46 +08:00
|
|
|
GIT_PATH_FUNC(rebase_path_dropped, "rebase-merge/dropped")
|
|
|
|
|
|
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
|
2020-09-25 13:49:12 +08:00
|
|
|
* the commit object name of the corresponding patch.
|
2017-01-02 23:26:43 +08:00
|
|
|
*/
|
|
|
|
|
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
|
|
|
/*
|
2019-11-06 01:07:23 +08:00
|
|
|
* The path of the file containing the OID of the "squash onto" commit, i.e.
|
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 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")
|
2020-08-18 01:40:02 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_cdate_is_adate, "rebase-merge/cdate_is_adate")
|
2020-08-18 01:40:03 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_ignore_date, "rebase-merge/ignore_date")
|
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")
|
2021-04-09 16:01:38 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_no_reschedule_failed_exec, "rebase-merge/no-reschedule-failed-exec")
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
static GIT_PATH_FUNC(rebase_path_drop_redundant_commits, "rebase-merge/drop_redundant_commits")
|
|
|
|
|
static GIT_PATH_FUNC(rebase_path_keep_redundant_commits, "rebase-merge/keep_redundant_commits")
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-03 07:45:34 +08:00
|
|
|
if (!opts->default_strategy && !strcmp(k, "pull.twohead")) {
|
|
|
|
|
int ret = git_config_string((const char**)&opts->default_strategy, k, v);
|
|
|
|
|
if (ret == 0) {
|
|
|
|
|
/*
|
|
|
|
|
* pull.twohead is allowed to be multi-valued; we only
|
|
|
|
|
* care about the first value.
|
|
|
|
|
*/
|
|
|
|
|
char *tmp = strchr(opts->default_strategy, ' ');
|
|
|
|
|
if (tmp)
|
|
|
|
|
*tmp = '\0';
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-13 19:46:21 +08:00
|
|
|
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;
|
sequencer: handle ignore_footer when parsing trailers
The append_signoff() function takes an "ignore_footer"
argument, which specifies a number of bytes at the end of
the message buffer which should not be considered (they
cannot contain trailers, and the trailer is spliced in
before them).
But to find the existing trailers, it calls into
has_conforming_trailer(). That function takes an
ignore_footer parameter, but since 967dfd4d56 (sequencer:
use trailer's trailer layout, 2016-11-02) the parameter is
completely ignored.
The trailer interface we're using takes a single string,
with no option to tell it to use part of the string.
However, since we have a mutable strbuf, we can work around
this by simply overwriting (and later restoring) the
boundary with a NUL.
I'm not sure if this can actually trigger a bug in practice.
It's easy to get a non-zero ignore_footer by doing something
like this:
git commit -F - --cleanup=verbatim <<-EOF
subject
body
Signed-off-by: me
# this looks like a comment, but is actually in the
# message! That makes the earlier s-o-b fake.
EOF
git commit --amend -s
There git-commit calls ignore_non_trailer() to count up the
"#" cruft, which becomes the ignore_footer header. But it
works even without this patch! That's because the trailer
code _also_ calls ignore_non_trailer() and skips the cruft,
too. So it happens to work because the only callers with a
non-zero ignore_footer are using the exact same function
that the trailer parser uses internally.
And that seems true for all of the current callers, but
there's nothing guaranteeing it. We're better off only
feeding the correct buffer to the trailer code in the first
place.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30 20:34:11 +08:00
|
|
|
char saved_char;
|
2013-02-12 18:17:34 +08:00
|
|
|
|
2018-08-23 08:50:37 +08:00
|
|
|
opts.no_divider = 1;
|
|
|
|
|
|
sequencer: handle ignore_footer when parsing trailers
The append_signoff() function takes an "ignore_footer"
argument, which specifies a number of bytes at the end of
the message buffer which should not be considered (they
cannot contain trailers, and the trailer is spliced in
before them).
But to find the existing trailers, it calls into
has_conforming_trailer(). That function takes an
ignore_footer parameter, but since 967dfd4d56 (sequencer:
use trailer's trailer layout, 2016-11-02) the parameter is
completely ignored.
The trailer interface we're using takes a single string,
with no option to tell it to use part of the string.
However, since we have a mutable strbuf, we can work around
this by simply overwriting (and later restoring) the
boundary with a NUL.
I'm not sure if this can actually trigger a bug in practice.
It's easy to get a non-zero ignore_footer by doing something
like this:
git commit -F - --cleanup=verbatim <<-EOF
subject
body
Signed-off-by: me
# this looks like a comment, but is actually in the
# message! That makes the earlier s-o-b fake.
EOF
git commit --amend -s
There git-commit calls ignore_non_trailer() to count up the
"#" cruft, which becomes the ignore_footer header. But it
works even without this patch! That's because the trailer
code _also_ calls ignore_non_trailer() and skips the cruft,
too. So it happens to work because the only callers with a
non-zero ignore_footer are using the exact same function
that the trailer parser uses internally.
And that seems true for all of the current callers, but
there's nothing guaranteeing it. We're better off only
feeding the correct buffer to the trailer code in the first
place.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30 20:34:11 +08:00
|
|
|
if (ignore_footer) {
|
|
|
|
|
saved_char = sb->buf[sb->len - ignore_footer];
|
|
|
|
|
sb->buf[sb->len - ignore_footer] = '\0';
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-23 08:46:23 +08:00
|
|
|
trailer_info_get(&info, sb->buf, &opts);
|
2013-02-12 18:17:34 +08:00
|
|
|
|
sequencer: handle ignore_footer when parsing trailers
The append_signoff() function takes an "ignore_footer"
argument, which specifies a number of bytes at the end of
the message buffer which should not be considered (they
cannot contain trailers, and the trailer is spliced in
before them).
But to find the existing trailers, it calls into
has_conforming_trailer(). That function takes an
ignore_footer parameter, but since 967dfd4d56 (sequencer:
use trailer's trailer layout, 2016-11-02) the parameter is
completely ignored.
The trailer interface we're using takes a single string,
with no option to tell it to use part of the string.
However, since we have a mutable strbuf, we can work around
this by simply overwriting (and later restoring) the
boundary with a NUL.
I'm not sure if this can actually trigger a bug in practice.
It's easy to get a non-zero ignore_footer by doing something
like this:
git commit -F - --cleanup=verbatim <<-EOF
subject
body
Signed-off-by: me
# this looks like a comment, but is actually in the
# message! That makes the earlier s-o-b fake.
EOF
git commit --amend -s
There git-commit calls ignore_non_trailer() to count up the
"#" cruft, which becomes the ignore_footer header. But it
works even without this patch! That's because the trailer
code _also_ calls ignore_non_trailer() and skips the cruft,
too. So it happens to work because the only callers with a
non-zero ignore_footer are using the exact same function
that the trailer parser uses internally.
And that seems true for all of the current callers, but
there's nothing guaranteeing it. We're better off only
feeding the correct buffer to the trailer code in the first
place.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30 20:34:11 +08:00
|
|
|
if (ignore_footer)
|
|
|
|
|
sb->buf[sb->len - ignore_footer] = saved_char;
|
|
|
|
|
|
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';
|
2020-02-16 05:36:36 +08:00
|
|
|
if (delete_ref("(rebase) 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);
|
2020-11-03 07:45:34 +08:00
|
|
|
free(opts->default_strategy);
|
2016-10-21 20:24:13 +08:00
|
|
|
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:
|
2020-02-16 05:36:36 +08:00
|
|
|
return N_("rebase");
|
2017-01-02 23:26:28 +08:00
|
|
|
}
|
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);
|
sequencer: avoid garbled merge machinery messages due to commit labels
sequencer's get_message() exists to provide good labels on conflict
hunks; see commits
d68565402a ("revert: clarify label on conflict hunks", 2010-03-20)
bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20)
043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11).
for background on this function. These labels are of the form
<commitID>... <commit summary>
or
parent of <commitID>... <commit summary>
These labels are then passed as branch names to the merge machinery.
However, these labels, as formatted, often also serve to confuse. For
example, if we have a rename involved in a content merge, then it
results in text such as the following:
<<<<<<<< HEAD:foo.c
int j;
========
int counter;
>>>>>>>> b01dface... Removed unnecessary stuff:bar.c
Or in various conflict messages, it can make it very difficult to read:
CONFLICT (rename/delete): foo.c deleted in b01dface... Removed
unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left
in tree.
CONFLICT (file location): dir1/foo.c added in b01dface... Removed
unnecessary stuff inside a directory that was renamed in HEAD,
suggesting it should perhaps be moved to dir2/foo.c.
Make a minor change to remove the ellipses and add parentheses around
the commit summary; this makes all three examples much easier to read:
<<<<<<<< HEAD:foo.c
int j;
========
int counter;
>>>>>>>> b01dface (Removed unnecessary stuff):bar.c
CONFLICT (rename/delete): foo.c deleted in b01dface (Removed
unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left
in tree.
CONFLICT (file location): dir1/foo.c added in b01dface (Removed
unnecessary stuff) inside a directory that was renamed in HEAD,
suggesting it should perhaps be moved to dir2/foo.c.
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
|
|
|
out->label = xstrfmt("%s (%s)", abbrev, out->subject);
|
2016-02-23 06:44:57 +08:00
|
|
|
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) {
|
cherry-pick: use better advice message
"git cherry-pick", upon seeing a conflict, says:
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
as if running "git commit" to conclude the resolution of
this single step were the end of the story. This stems from
the fact that the command originally was to pick a single
commit and not a range of commits, and the message was
written back then and has not been adjusted.
When picking a range of commits and the command stops with a
conflict in the middle of the range, however, after
resolving the conflict and (optionally) recording the result
with "git commit", the user has to run "git cherry-pick
--continue" to have the rest of the range dealt with,
"--skip" to drop the current commit, or "--abort" to discard
the series.
Suggest use of "git cherry-pick --continue/--skip/--abort"
so that the message also covers the case where a range of
commits are being picked.
Similarly, this optimization can be applied to git revert,
suggest use of "git revert --continue/--skip/--abort" so
that the message also covers the case where a range of
commits are being reverted.
It is worth mentioning that now we use advice() to print
the content of GIT_CHERRY_PICK_HELP in print_advice(), each
line of output will start with "hint: ".
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Hariom Verma <hariom18599@gmail.com>
Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: ZheNing Hu <adlternative@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-22 21:08:41 +08:00
|
|
|
advise("%s\n", msg);
|
2012-01-12 02:15:57 +08:00
|
|
|
/*
|
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
|
|
|
|
|
*/
|
2020-08-22 00:59:35 +08:00
|
|
|
refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
|
|
|
|
|
NULL, 0);
|
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>'"));
|
cherry-pick: use better advice message
"git cherry-pick", upon seeing a conflict, says:
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
as if running "git commit" to conclude the resolution of
this single step were the end of the story. This stems from
the fact that the command originally was to pick a single
commit and not a range of commits, and the message was
written back then and has not been adjusted.
When picking a range of commits and the command stops with a
conflict in the middle of the range, however, after
resolving the conflict and (optionally) recording the result
with "git commit", the user has to run "git cherry-pick
--continue" to have the rest of the range dealt with,
"--skip" to drop the current commit, or "--abort" to discard
the series.
Suggest use of "git cherry-pick --continue/--skip/--abort"
so that the message also covers the case where a range of
commits are being picked.
Similarly, this optimization can be applied to git revert,
suggest use of "git revert --continue/--skip/--abort" so
that the message also covers the case where a range of
commits are being reverted.
It is worth mentioning that now we use advice() to print
the content of GIT_CHERRY_PICK_HELP in print_advice(), each
line of output will start with "hint: ".
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Hariom Verma <hariom18599@gmail.com>
Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: ZheNing Hu <adlternative@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-22 21:08:41 +08:00
|
|
|
else if (opts->action == REPLAY_PICK)
|
|
|
|
|
advise(_("After resolving the conflicts, mark them with\n"
|
|
|
|
|
"\"git add/rm <pathspec>\", then run\n"
|
|
|
|
|
"\"git cherry-pick --continue\".\n"
|
|
|
|
|
"You can instead skip this commit with \"git cherry-pick --skip\".\n"
|
|
|
|
|
"To abort and get back to the state before \"git cherry-pick\",\n"
|
|
|
|
|
"run \"git cherry-pick --abort\"."));
|
|
|
|
|
else if (opts->action == REPLAY_REVERT)
|
|
|
|
|
advise(_("After resolving the conflicts, mark them with\n"
|
|
|
|
|
"\"git add/rm <pathspec>\", then run\n"
|
|
|
|
|
"\"git revert --continue\".\n"
|
|
|
|
|
"You can instead skip this commit with \"git revert --skip\".\n"
|
|
|
|
|
"To abort and get back to the state before \"git revert\",\n"
|
|
|
|
|
"run \"git revert --abort\"."));
|
2012-02-22 08:44:17 +08:00
|
|
|
else
|
cherry-pick: use better advice message
"git cherry-pick", upon seeing a conflict, says:
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
as if running "git commit" to conclude the resolution of
this single step were the end of the story. This stems from
the fact that the command originally was to pick a single
commit and not a range of commits, and the message was
written back then and has not been adjusted.
When picking a range of commits and the command stops with a
conflict in the middle of the range, however, after
resolving the conflict and (optionally) recording the result
with "git commit", the user has to run "git cherry-pick
--continue" to have the rest of the range dealt with,
"--skip" to drop the current commit, or "--abort" to discard
the series.
Suggest use of "git cherry-pick --continue/--skip/--abort"
so that the message also covers the case where a range of
commits are being picked.
Similarly, this optimization can be applied to git revert,
suggest use of "git revert --continue/--skip/--abort" so
that the message also covers the case where a range of
commits are being reverted.
It is worth mentioning that now we use advice() to print
the content of GIT_CHERRY_PICK_HELP in print_advice(), each
line of output will start with "hint: ".
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Hariom Verma <hariom18599@gmail.com>
Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: ZheNing Hu <adlternative@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-22 21:08:41 +08:00
|
|
|
BUG("unexpected pick action in print_advice()");
|
2012-02-22 08:44:17 +08:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:27:54 +08:00
|
|
|
int read_oneliner(struct strbuf *buf,
|
2020-04-07 22:27:52 +08:00
|
|
|
const char *path, unsigned flags)
|
2016-10-21 20:25:08 +08:00
|
|
|
{
|
|
|
|
|
int orig_len = buf->len;
|
|
|
|
|
|
|
|
|
|
if (strbuf_read_file(buf, path, 0) < 0) {
|
2020-04-07 22:27:53 +08:00
|
|
|
if ((flags & READ_ONELINER_WARN_MISSING) ||
|
|
|
|
|
(errno != ENOENT && errno != ENOTDIR))
|
2020-04-07 22:27:51 +08:00
|
|
|
warning_errno(_("could not read '%s'"), path);
|
2016-10-21 20:25:08 +08:00
|
|
|
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';
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:27:52 +08:00
|
|
|
if ((flags & READ_ONELINER_SKIP_IF_EMPTY) && buf->len == orig_len)
|
2016-10-21 20:25:08 +08:00
|
|
|
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
|
|
|
|
2021-08-23 18:44:00 +08:00
|
|
|
if (advice_enabled(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) ?
|
2021-04-26 09:02:56 +08:00
|
|
|
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;
|
2020-11-03 07:45:34 +08:00
|
|
|
struct merge_result result;
|
2019-08-18 02:41:30 +08:00
|
|
|
struct tree *next_tree, *base_tree, *head_tree;
|
2020-11-03 07:45:34 +08:00
|
|
|
int clean, show_output;
|
avoid computing zero offsets from NULL pointer
The Undefined Behavior Sanitizer in clang-11 seems to have learned a new
trick: it complains about computing offsets from a NULL pointer, even if
that offset is 0. This causes numerous test failures. For example, from
t1090:
unpack-trees.c:1355:41: runtime error: applying zero offset to null pointer
...
not ok 6 - in partial clone, sparse checkout only fetches needed blobs
The code in question looks like this:
struct cache_entry **cache_end = cache + nr;
...
while (cache != cache_end)
and we sometimes pass in a NULL and 0 for "cache" and "nr". This is
conceptually fine, as "cache_end" would be equal to "cache" in this
case, and we wouldn't enter the loop at all. But computing even a zero
offset violates the C standard. And given the fact that UBSan is
noticing this behavior, this might be a potential problem spot if the
compiler starts making unexpected assumptions based on undefined
behavior.
So let's just avoid it, which is pretty easy. In some cases we can just
switch to iterating with a numeric index (as we do in sequencer.c here).
In other cases (like the cache_end one) the use of an end pointer is
more natural; we can keep that by just explicitly checking for the
NULL/0 case when assigning the end pointer.
Note that there are two ways you can write this latter case, checking
for the pointer:
cache_end = cache ? cache + nr : cache;
or the size:
cache_end = nr ? cache + nr : cache;
For the case of a NULL/0 ptr/len combo, they are equivalent. But writing
it the second way (as this patch does) has the property that if somebody
were to incorrectly pass a NULL pointer with a non-zero length, we'd
continue to notice and segfault, rather than silently pretending the
length was zero.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-29 13:46:47 +08:00
|
|
|
int i;
|
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
|
|
|
|
avoid computing zero offsets from NULL pointer
The Undefined Behavior Sanitizer in clang-11 seems to have learned a new
trick: it complains about computing offsets from a NULL pointer, even if
that offset is 0. This causes numerous test failures. For example, from
t1090:
unpack-trees.c:1355:41: runtime error: applying zero offset to null pointer
...
not ok 6 - in partial clone, sparse checkout only fetches needed blobs
The code in question looks like this:
struct cache_entry **cache_end = cache + nr;
...
while (cache != cache_end)
and we sometimes pass in a NULL and 0 for "cache" and "nr". This is
conceptually fine, as "cache_end" would be equal to "cache" in this
case, and we wouldn't enter the loop at all. But computing even a zero
offset violates the C standard. And given the fact that UBSan is
noticing this behavior, this might be a potential problem spot if the
compiler starts making unexpected assumptions based on undefined
behavior.
So let's just avoid it, which is pretty easy. In some cases we can just
switch to iterating with a numeric index (as we do in sequencer.c here).
In other cases (like the cache_end one) the use of an end pointer is
more natural; we can keep that by just explicitly checking for the
NULL/0 case when assigning the end pointer.
Note that there are two ways you can write this latter case, checking
for the pointer:
cache_end = cache ? cache + nr : cache;
or the size:
cache_end = nr ? cache + nr : cache;
For the case of a NULL/0 ptr/len combo, they are equivalent. But writing
it the second way (as this patch does) has the property that if somebody
were to incorrectly pass a NULL pointer with a non-zero length, we'd
continue to notice and segfault, rather than silently pretending the
length was zero.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-29 13:46:47 +08:00
|
|
|
for (i = 0; i < opts->xopts_nr; i++)
|
|
|
|
|
parse_merge_opt(&o, opts->xopts[i]);
|
2012-01-12 02:15:57 +08:00
|
|
|
|
Change default merge backend from recursive to ort
There are a few reasons to switch the default:
* Correctness
* Extensibility
* Performance
I'll provide some summaries about each.
=== Correctness ===
The original impetus for a new merge backend was to fix issues that were
difficult to fix within recursive's design. The success with this goal
is perhaps most easily demonstrated by running the following:
$ git grep -2 KNOWN_FAILURE t/ | grep -A 4 GIT_TEST_MERGE_ALGORITHM
$ git grep test_expect_merge_algorithm.failure.success t/
$ git grep test_expect_merge_algorithm.success.failure t/
In order, these greps show:
* Seven sets of submodule tests (10 total tests) that fail with
recursive but succeed with ort
* 22 other tests that fail with recursive, but succeed with ort
* 0 tests that pass with recursive, but fail with ort
=== Extensibility ===
Being able to perform merges without touching the working tree or index
makes it possible to create new features that were difficult with the
old backend:
* Merging, cherry-picking, rebasing, reverting in bare repositories...
or just on branches that aren't checked out.
* `git diff AUTO_MERGE` -- ability to see what changes the user has
made to resolve conflicts so far (see commit 5291828df8 ("merge-ort:
write $GIT_DIR/AUTO_MERGE whenever we hit a conflict", 2021-03-20)
* A --remerge-diff option for log/show, used to show diffs for merges
that display the difference between what an automatic merge would
have created and what was recorded in the merge. (This option will
often result in an empty diff because many merges are clean, but for
the non-clean ones it will show how conflicts were fixed including
the removal of conflict markers, and also show additional changes
made outside of conflict regions to e.g. fix semantic conflicts.)
* A --remerge-diff-only option for log/show, similar to --remerge-diff
but also showing how cherry-picks or reverts differed from what an
automatic cherry-pick or revert would provide.
The last three have been implemented already (though only one has been
submitted upstream so far; the others were waiting for performance work
to complete), and I still plan to implement the first one.
=== Performance ===
I'll quote from the summary of my final optimization for merge-ort
(while fixing the testcase name from 'no-renames' to 'few-renames'):
Timings
Infinite
merge- merge- Parallelism
recursive recursive of rename merge-ort
v2.30.0 current detection current
---------- --------- ----------- ---------
few-renames: 18.912 s 18.030 s 11.699 s 198.3 ms
mega-renames: 5964.031 s 361.281 s 203.886 s 661.8 ms
just-one-mega: 149.583 s 11.009 s 7.553 s 264.6 ms
Speedup factors
Infinite
merge- merge- Parallelism
recursive recursive of rename
v2.30.0 current detection merge-ort
---------- --------- ----------- ---------
few-renames: 1 1.05 1.6 95
mega-renames: 1 16.5 29 9012
just-one-mega: 1 13.6 20 565
And, for partial clone users:
Factor reduction in number of objects needed
Infinite
merge- merge- Parallelism
recursive recursive of rename
v2.30.0 current detection merge-ort
---------- --------- ----------- ---------
mega-renames: 1 1 1 181.3
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-04 13:38:01 +08:00
|
|
|
if (!opts->strategy || !strcmp(opts->strategy, "ort")) {
|
2020-11-03 07:45:34 +08:00
|
|
|
memset(&result, 0, sizeof(result));
|
|
|
|
|
merge_incore_nonrecursive(&o, base_tree, head_tree, next_tree,
|
|
|
|
|
&result);
|
|
|
|
|
show_output = !is_rebase_i(opts) || !result.clean;
|
|
|
|
|
/*
|
|
|
|
|
* TODO: merge_switch_to_result will update index/working tree;
|
|
|
|
|
* we only really want to do that if !result.clean || this is
|
|
|
|
|
* the final patch to be picked. But determining this is the
|
|
|
|
|
* final patch would take some work, and "head_tree" would need
|
|
|
|
|
* to be replace with the tree the index matched before we
|
|
|
|
|
* started doing any picks.
|
|
|
|
|
*/
|
|
|
|
|
merge_switch_to_result(&o, head_tree, &result, 1, show_output);
|
|
|
|
|
clean = result.clean;
|
|
|
|
|
} else {
|
2021-09-08 19:24:00 +08:00
|
|
|
ensure_full_index(r->index);
|
2020-11-03 07:45:34 +08:00
|
|
|
clean = merge_trees(&o, head_tree, next_tree, base_tree);
|
|
|
|
|
if (is_rebase_i(opts) && clean <= 0)
|
|
|
|
|
fputs(o.obuf.buf, stdout);
|
|
|
|
|
strbuf_release(&o.obuf);
|
|
|
|
|
}
|
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
|
2020-02-16 05:36:36 +08:00
|
|
|
* "rebase".
|
2017-01-02 23:26:28 +08:00
|
|
|
*/
|
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 (!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;
|
2020-01-13 04:27:41 +08:00
|
|
|
*name = kv.items[name_i].util;
|
|
|
|
|
*email = kv.items[email_i].util;
|
|
|
|
|
*date = kv.items[date_i].util;
|
2018-10-31 18:15:55 +08:00
|
|
|
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
|
2020-07-29 04:25:12 +08:00
|
|
|
* file with shell quoting into struct strvec. Returns -1 on
|
2018-10-31 18:15:56 +08:00
|
|
|
* error, 0 otherwise.
|
2016-10-21 20:25:04 +08:00
|
|
|
*/
|
2020-07-29 04:25:12 +08:00
|
|
|
static int read_env_script(struct strvec *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
|
|
|
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_pushf(env, "GIT_AUTHOR_NAME=%s", name);
|
|
|
|
|
strvec_pushf(env, "GIT_AUTHOR_EMAIL=%s", email);
|
|
|
|
|
strvec_pushf(env, "GIT_AUTHOR_DATE=%s", date);
|
2018-10-31 18:15:56 +08:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-04 03:37:01 +08:00
|
|
|
static const char *author_date_from_env_array(const struct strvec *env)
|
2020-08-18 01:40:02 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
const char *date;
|
|
|
|
|
|
2020-09-04 03:37:01 +08:00
|
|
|
for (i = 0; i < env->nr; i++)
|
|
|
|
|
if (skip_prefix(env->v[i],
|
2020-08-18 01:40:02 +08:00
|
|
|
"GIT_AUTHOR_DATE=", &date))
|
|
|
|
|
return date;
|
|
|
|
|
/*
|
|
|
|
|
* If GIT_AUTHOR_DATE is missing we should have already errored out when
|
|
|
|
|
* reading the script
|
|
|
|
|
*/
|
|
|
|
|
BUG("GIT_AUTHOR_DATE missing from author script");
|
|
|
|
|
}
|
|
|
|
|
|
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)
|
2021-01-29 00:16:42 +08:00
|
|
|
#define VERBATIM_MSG (1<<6)
|
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
|
|
|
*/
|
2020-09-30 20:29:31 +08:00
|
|
|
static int run_git_commit(const char *defmsg,
|
2018-11-10 13:48:56 +08:00
|
|
|
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
|
|
|
|
2021-01-29 00:16:42 +08:00
|
|
|
if ((flags & CLEANUP_MSG) && (flags & VERBATIM_MSG))
|
|
|
|
|
BUG("CLEANUP_MSG and VERBATIM_MSG are mutually exclusive");
|
|
|
|
|
|
2017-01-02 23:35:29 +08:00
|
|
|
cmd.git_cmd = 1;
|
|
|
|
|
|
2021-11-03 05:30:51 +08:00
|
|
|
if (is_rebase_i(opts) &&
|
|
|
|
|
((opts->committer_date_is_author_date && !opts->ignore_date) ||
|
|
|
|
|
!(!defmsg && (flags & AMEND_MSG))) &&
|
2021-08-20 23:40:37 +08:00
|
|
|
read_env_script(&cmd.env_array)) {
|
2018-08-11 00:51:32 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2020-08-18 01:40:02 +08:00
|
|
|
if (opts->committer_date_is_author_date)
|
2020-09-04 03:37:01 +08:00
|
|
|
strvec_pushf(&cmd.env_array, "GIT_COMMITTER_DATE=%s",
|
|
|
|
|
opts->ignore_date ?
|
|
|
|
|
"" :
|
|
|
|
|
author_date_from_env_array(&cmd.env_array));
|
2020-08-18 01:40:03 +08:00
|
|
|
if (opts->ignore_date)
|
2020-09-04 03:37:01 +08:00
|
|
|
strvec_push(&cmd.env_array, "GIT_AUTHOR_DATE=");
|
2020-08-18 01:40:02 +08:00
|
|
|
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "commit");
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2017-03-24 00:07:17 +08:00
|
|
|
if (!(flags & VERIFY_MSG))
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "-n");
|
2017-03-24 00:07:11 +08:00
|
|
|
if ((flags & AMEND_MSG))
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "--amend");
|
2014-06-20 05:28:20 +08:00
|
|
|
if (opts->gpg_sign)
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
|
2020-04-03 18:28:03 +08:00
|
|
|
else
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "--no-gpg-sign");
|
2016-10-21 20:25:04 +08:00
|
|
|
if (defmsg)
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_pushl(&cmd.args, "-F", defmsg, NULL);
|
2018-04-28 04:48:28 +08:00
|
|
|
else if (!(flags & EDIT_MSG))
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_pushl(&cmd.args, "-C", "HEAD", NULL);
|
2017-03-24 00:07:11 +08:00
|
|
|
if ((flags & CLEANUP_MSG))
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "--cleanup=strip");
|
2021-01-29 00:16:42 +08:00
|
|
|
if ((flags & VERBATIM_MSG))
|
|
|
|
|
strvec_push(&cmd.args, "--cleanup=verbatim");
|
2017-03-24 00:07:11 +08:00
|
|
|
if ((flags & EDIT_MSG))
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_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)
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_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))
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_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))
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_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,
|
2021-04-26 09:02:56 +08:00
|
|
|
old_head ? &old_head->object.oid : null_oid(),
|
2017-11-17 19:34:47 +08:00
|
|
|
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;
|
|
|
|
|
int code;
|
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2021-11-26 06:52:20 +08:00
|
|
|
const char *hook_path = find_hook("post-rewrite");
|
2017-11-17 19:34:48 +08:00
|
|
|
|
2021-11-26 06:52:20 +08:00
|
|
|
if (!hook_path)
|
2017-11-17 19:34:48 +08:00
|
|
|
return 0;
|
|
|
|
|
|
2021-11-26 06:52:20 +08:00
|
|
|
strvec_pushl(&proc.args, hook_path, "amend", NULL);
|
2017-11-17 19:34:48 +08:00
|
|
|
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
|
|
|
{
|
2019-10-15 18:25:31 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
const char *name, *arg1 = NULL, *arg2 = NULL;
|
2018-01-24 20:34:22 +08:00
|
|
|
|
|
|
|
|
name = git_path_commit_editmsg();
|
|
|
|
|
if (write_message(msg->buf, msg->len, name, 0))
|
|
|
|
|
return -1;
|
|
|
|
|
|
2019-10-15 18:25:31 +08:00
|
|
|
if (commit) {
|
|
|
|
|
arg1 = "commit";
|
|
|
|
|
arg2 = commit;
|
|
|
|
|
} else {
|
|
|
|
|
arg1 = "message";
|
|
|
|
|
}
|
|
|
|
|
if (run_commit_hook(0, r->index_file, "prepare-commit-msg", name,
|
|
|
|
|
arg1, arg2, NULL))
|
2018-01-24 20:34:22 +08:00
|
|
|
ret = error(_("'prepare-commit-msg' hook failed"));
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
{
|
2021-07-25 06:06:52 +08:00
|
|
|
char *user_config = interpolate_path("~/.gitconfig", 0);
|
2017-11-24 19:07:54 +08:00
|
|
|
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;
|
2021-10-16 17:39:23 +08:00
|
|
|
struct ref_store *refs;
|
|
|
|
|
int resolve_errno;
|
2017-11-24 19:07:54 +08:00
|
|
|
|
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);
|
2021-08-23 18:44:00 +08:00
|
|
|
if (advice_enabled(ADVICE_IMPLICIT_IDENTITY)) {
|
2017-11-24 19:07:54 +08:00
|
|
|
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);
|
|
|
|
|
|
2021-10-16 17:39:23 +08:00
|
|
|
refs = get_main_ref_store(the_repository);
|
2021-10-16 17:39:27 +08:00
|
|
|
head = refs_resolve_ref_unsafe(refs, "HEAD", 0, NULL, NULL,
|
2021-10-16 17:39:23 +08:00
|
|
|
&resolve_errno);
|
|
|
|
|
if (!head) {
|
|
|
|
|
errno = resolve_errno;
|
2017-11-24 19:07:54 +08:00
|
|
|
die_errno(_("unable to resolve HEAD after creating commit"));
|
2021-10-16 17:39:23 +08:00
|
|
|
}
|
2017-11-24 19:07:54 +08:00
|
|
|
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;
|
2019-08-19 17:18:23 +08:00
|
|
|
struct commit *current_head = NULL;
|
2017-11-24 19:07:57 +08:00
|
|
|
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;
|
2020-01-13 04:27:41 +08:00
|
|
|
char *amend_author = NULL;
|
2020-08-18 01:40:02 +08:00
|
|
|
const char *committer = 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;
|
|
|
|
|
|
2021-01-29 00:16:42 +08:00
|
|
|
if ((flags & CLEANUP_MSG) && (flags & VERBATIM_MSG))
|
|
|
|
|
BUG("CLEANUP_MSG and VERBATIM_MSG are mutually exclusive");
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
if (parse_head(r, ¤t_head))
|
2017-11-24 19:07:57 +08:00
|
|
|
return -1;
|
2020-01-13 04:27:41 +08:00
|
|
|
|
2017-11-24 19:07:57 +08:00
|
|
|
if (flags & AMEND_MSG) {
|
2020-02-23 04:17:42 +08:00
|
|
|
const char *exclude_gpgsig[] = { "gpgsig", "gpgsig-sha256", NULL };
|
2017-11-24 19:07:57 +08:00
|
|
|
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
|
|
|
}
|
2020-01-13 04:27:41 +08:00
|
|
|
author = amend_author = get_author(message);
|
2017-11-24 19:07:57 +08:00
|
|
|
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);
|
2019-08-19 17:18:23 +08:00
|
|
|
} else if (current_head &&
|
|
|
|
|
(!(flags & CREATE_ROOT_COMMIT) || (flags & AMEND_MSG))) {
|
2017-11-24 19:07:57 +08:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-23 03:43:03 +08:00
|
|
|
if (!(flags & ALLOW_EMPTY)) {
|
|
|
|
|
struct commit *first_parent = current_head;
|
|
|
|
|
|
|
|
|
|
if (flags & AMEND_MSG) {
|
|
|
|
|
if (current_head->parents) {
|
|
|
|
|
first_parent = current_head->parents->item;
|
|
|
|
|
if (repo_parse_commit(r, first_parent)) {
|
|
|
|
|
res = error(_("could not parse HEAD commit"));
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
first_parent = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (oideq(first_parent
|
|
|
|
|
? get_commit_tree_oid(first_parent)
|
|
|
|
|
: the_hash_algo->empty_tree,
|
|
|
|
|
&tree)) {
|
|
|
|
|
res = 1; /* run 'git commit' to display error message */
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2017-11-24 19:07:57 +08:00
|
|
|
}
|
|
|
|
|
|
2021-09-27 03:03:28 +08:00
|
|
|
if (hook_exists("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;
|
2021-01-29 00:16:42 +08:00
|
|
|
else if (flags & VERBATIM_MSG)
|
|
|
|
|
cleanup = COMMIT_MSG_CLEANUP_NONE;
|
2019-03-29 19:08:42 +08:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 01:40:02 +08:00
|
|
|
if (opts->committer_date_is_author_date) {
|
|
|
|
|
struct ident_split id;
|
|
|
|
|
struct strbuf date = STRBUF_INIT;
|
|
|
|
|
|
2020-08-18 01:40:03 +08:00
|
|
|
if (!opts->ignore_date) {
|
|
|
|
|
if (split_ident_line(&id, author, (int)strlen(author)) < 0) {
|
|
|
|
|
res = error(_("invalid author identity '%s'"),
|
|
|
|
|
author);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
if (!id.date_begin) {
|
|
|
|
|
res = error(_(
|
|
|
|
|
"corrupt author: missing date information"));
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
strbuf_addf(&date, "@%.*s %.*s",
|
|
|
|
|
(int)(id.date_end - id.date_begin),
|
|
|
|
|
id.date_begin,
|
|
|
|
|
(int)(id.tz_end - id.tz_begin),
|
|
|
|
|
id.tz_begin);
|
|
|
|
|
} else {
|
|
|
|
|
reset_ident_date();
|
2020-08-18 01:40:02 +08:00
|
|
|
}
|
2020-10-23 15:26:30 +08:00
|
|
|
committer = fmt_ident(getenv("GIT_COMMITTER_NAME"),
|
|
|
|
|
getenv("GIT_COMMITTER_EMAIL"),
|
2020-08-18 01:40:03 +08:00
|
|
|
WANT_COMMITTER_IDENT,
|
|
|
|
|
opts->ignore_date ? NULL : date.buf,
|
2020-08-18 01:40:02 +08:00
|
|
|
IDENT_STRICT);
|
|
|
|
|
strbuf_release(&date);
|
|
|
|
|
} else {
|
|
|
|
|
reset_ident_date();
|
|
|
|
|
}
|
2018-04-19 02:15:04 +08:00
|
|
|
|
2020-08-18 01:40:03 +08:00
|
|
|
if (opts->ignore_date) {
|
|
|
|
|
struct ident_split id;
|
|
|
|
|
char *name, *email;
|
2018-04-19 02:15:04 +08:00
|
|
|
|
2020-08-18 01:40:03 +08:00
|
|
|
if (split_ident_line(&id, author, strlen(author)) < 0) {
|
|
|
|
|
error(_("invalid author identity '%s'"), author);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
name = xmemdupz(id.name_begin, id.name_end - id.name_begin);
|
|
|
|
|
email = xmemdupz(id.mail_begin, id.mail_end - id.mail_begin);
|
|
|
|
|
author = fmt_ident(name, email, WANT_AUTHOR_IDENT, NULL,
|
|
|
|
|
IDENT_STRICT);
|
|
|
|
|
free(name);
|
|
|
|
|
free(email);
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 01:40:01 +08:00
|
|
|
if (commit_tree_extended(msg->buf, msg->len, &tree, parents, oid,
|
2020-08-18 01:40:02 +08:00
|
|
|
author, committer, 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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-15 18:25:32 +08:00
|
|
|
run_commit_hook(0, r->index_file, "post-commit", NULL);
|
2017-11-24 19:07:57 +08:00
|
|
|
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);
|
2020-01-13 04:27:41 +08:00
|
|
|
free(amend_author);
|
2017-11-24 19:07:57 +08:00
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-07 00:06:12 +08:00
|
|
|
static int write_rebase_head(struct object_id *oid)
|
|
|
|
|
{
|
|
|
|
|
if (update_ref("rebase", "REBASE_HEAD", oid,
|
|
|
|
|
NULL, REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR))
|
|
|
|
|
return error(_("could not update %s"), "REBASE_HEAD");
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_commit(struct repository *r,
|
|
|
|
|
const char *msg_file, const char *author,
|
2019-12-07 00:06:12 +08:00
|
|
|
struct replay_opts *opts, unsigned int flags,
|
|
|
|
|
struct object_id *oid)
|
2017-11-24 19:07:57 +08:00
|
|
|
{
|
|
|
|
|
int res = 1;
|
|
|
|
|
|
2019-08-19 17:18:23 +08:00
|
|
|
if (!(flags & EDIT_MSG) && !(flags & VERIFY_MSG)) {
|
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) {
|
2020-08-22 00:59:35 +08:00
|
|
|
refs_delete_ref(get_main_ref_store(r), "",
|
|
|
|
|
"CHERRY_PICK_HEAD", NULL, 0);
|
2018-11-10 13:48:56 +08:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-12-07 00:06:12 +08:00
|
|
|
if (res == 1) {
|
|
|
|
|
if (is_rebase_i(opts) && oid)
|
|
|
|
|
if (write_rebase_head(oid))
|
|
|
|
|
return -1;
|
2020-09-30 20:29:31 +08:00
|
|
|
return run_git_commit(msg_file, opts, flags);
|
2019-12-07 00:06:12 +08:00
|
|
|
}
|
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
|
|
|
/*
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
* Should empty commits be allowed? Return status:
|
|
|
|
|
* <0: Error in is_index_unchanged(r) or is_original_commit_empty(commit)
|
|
|
|
|
* 0: Halt on empty commit
|
|
|
|
|
* 1: Allow empty commit
|
|
|
|
|
* 2: Drop empty commit
|
2012-05-30 08:14:41 +08:00
|
|
|
*/
|
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
|
|
|
{
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
int index_unchanged, originally_empty;
|
2012-05-30 08:14:41 +08:00
|
|
|
|
|
|
|
|
/*
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
* Four cases:
|
2012-05-30 08:14:41 +08:00
|
|
|
*
|
|
|
|
|
* (1) we do not allow empty at all and error out.
|
|
|
|
|
*
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
* (2) we allow ones that were initially empty, and
|
|
|
|
|
* just drop the ones that become empty
|
2012-05-30 08:14:41 +08:00
|
|
|
*
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
* (3) we allow ones that were initially empty, but
|
|
|
|
|
* halt for the ones that become empty;
|
|
|
|
|
*
|
|
|
|
|
* (4) we allow both.
|
2012-05-30 08:14:41 +08:00
|
|
|
*/
|
|
|
|
|
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;
|
|
|
|
|
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
originally_empty = is_original_commit_empty(commit);
|
|
|
|
|
if (originally_empty < 0)
|
|
|
|
|
return originally_empty;
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
if (originally_empty)
|
2012-05-30 08:14:41 +08:00
|
|
|
return 1;
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
else if (opts->drop_redundant_commits)
|
|
|
|
|
return 2;
|
|
|
|
|
else
|
|
|
|
|
return 0;
|
2012-05-30 08:14:41 +08:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
{
|
2020-03-30 20:42:35 +08:00
|
|
|
if (command < TODO_COMMENT)
|
2017-12-06 01:52:34 +08:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-30 02:20:47 +08:00
|
|
|
enum todo_item_flags {
|
|
|
|
|
TODO_EDIT_MERGE_MSG = (1 << 0),
|
|
|
|
|
TODO_REPLACE_FIXUP_MSG = (1 << 1),
|
|
|
|
|
TODO_EDIT_FIXUP_MSG = (1 << 2),
|
|
|
|
|
};
|
|
|
|
|
|
2021-01-30 02:20:46 +08:00
|
|
|
static const char first_commit_msg_str[] = N_("This is the 1st commit message:");
|
|
|
|
|
static const char nth_commit_msg_fmt[] = N_("This is the commit message #%d:");
|
2021-01-30 02:20:47 +08:00
|
|
|
static const char skip_first_commit_msg_str[] = N_("The 1st commit message will be skipped:");
|
2021-01-30 02:20:46 +08:00
|
|
|
static const char skip_nth_commit_msg_fmt[] = N_("The commit message #%d will be skipped:");
|
|
|
|
|
static const char combined_commit_msg_fmt[] = N_("This is a combination of %d commits.");
|
|
|
|
|
|
2021-02-09 03:25:20 +08:00
|
|
|
static int is_fixup_flag(enum todo_command command, unsigned flag)
|
2021-01-19 15:40:57 +08:00
|
|
|
{
|
2021-01-30 02:20:47 +08:00
|
|
|
return command == TODO_FIXUP && ((flag & TODO_REPLACE_FIXUP_MSG) ||
|
|
|
|
|
(flag & TODO_EDIT_FIXUP_MSG));
|
|
|
|
|
}
|
2021-01-30 02:20:44 +08:00
|
|
|
|
2021-01-30 02:20:47 +08:00
|
|
|
/*
|
|
|
|
|
* Wrapper around strbuf_add_commented_lines() which avoids double
|
|
|
|
|
* commenting commit subjects.
|
|
|
|
|
*/
|
|
|
|
|
static void add_commented_lines(struct strbuf *buf, const void *str, size_t len)
|
|
|
|
|
{
|
|
|
|
|
const char *s = str;
|
|
|
|
|
while (len > 0 && s[0] == comment_line_char) {
|
|
|
|
|
size_t count;
|
|
|
|
|
const char *n = memchr(s, '\n', len);
|
|
|
|
|
if (!n)
|
|
|
|
|
count = len;
|
|
|
|
|
else
|
|
|
|
|
count = n - s + 1;
|
|
|
|
|
strbuf_add(buf, s, count);
|
|
|
|
|
s += count;
|
|
|
|
|
len -= count;
|
|
|
|
|
}
|
|
|
|
|
strbuf_add_commented_lines(buf, s, len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Does the current fixup chain contain a squash command? */
|
|
|
|
|
static int seen_squash(struct replay_opts *opts)
|
|
|
|
|
{
|
|
|
|
|
return starts_with(opts->current_fixups.buf, "squash") ||
|
|
|
|
|
strstr(opts->current_fixups.buf, "\nsquash");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void update_comment_bufs(struct strbuf *buf1, struct strbuf *buf2, int n)
|
|
|
|
|
{
|
|
|
|
|
strbuf_setlen(buf1, 2);
|
|
|
|
|
strbuf_addf(buf1, _(nth_commit_msg_fmt), n);
|
|
|
|
|
strbuf_addch(buf1, '\n');
|
|
|
|
|
strbuf_setlen(buf2, 2);
|
|
|
|
|
strbuf_addf(buf2, _(skip_nth_commit_msg_fmt), n);
|
|
|
|
|
strbuf_addch(buf2, '\n');
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Comment out any un-commented commit messages, updating the message comments
|
|
|
|
|
* to say they will be skipped but do not comment out the empty lines that
|
|
|
|
|
* surround commit messages and their comments.
|
|
|
|
|
*/
|
|
|
|
|
static void update_squash_message_for_fixup(struct strbuf *msg)
|
|
|
|
|
{
|
|
|
|
|
void (*copy_lines)(struct strbuf *, const void *, size_t) = strbuf_add;
|
|
|
|
|
struct strbuf buf1 = STRBUF_INIT, buf2 = STRBUF_INIT;
|
|
|
|
|
const char *s, *start;
|
|
|
|
|
char *orig_msg;
|
|
|
|
|
size_t orig_msg_len;
|
|
|
|
|
int i = 1;
|
|
|
|
|
|
|
|
|
|
strbuf_addf(&buf1, "# %s\n", _(first_commit_msg_str));
|
|
|
|
|
strbuf_addf(&buf2, "# %s\n", _(skip_first_commit_msg_str));
|
|
|
|
|
s = start = orig_msg = strbuf_detach(msg, &orig_msg_len);
|
|
|
|
|
while (s) {
|
|
|
|
|
const char *next;
|
|
|
|
|
size_t off;
|
|
|
|
|
if (skip_prefix(s, buf1.buf, &next)) {
|
|
|
|
|
/*
|
|
|
|
|
* Copy the last message, preserving the blank line
|
|
|
|
|
* preceding the current line
|
|
|
|
|
*/
|
|
|
|
|
off = (s > start + 1 && s[-2] == '\n') ? 1 : 0;
|
|
|
|
|
copy_lines(msg, start, s - start - off);
|
|
|
|
|
if (off)
|
|
|
|
|
strbuf_addch(msg, '\n');
|
|
|
|
|
/*
|
|
|
|
|
* The next message needs to be commented out but the
|
|
|
|
|
* message header is already commented out so just copy
|
|
|
|
|
* it and the blank line that follows it.
|
|
|
|
|
*/
|
|
|
|
|
strbuf_addbuf(msg, &buf2);
|
|
|
|
|
if (*next == '\n')
|
|
|
|
|
strbuf_addch(msg, *next++);
|
|
|
|
|
start = s = next;
|
|
|
|
|
copy_lines = add_commented_lines;
|
|
|
|
|
update_comment_bufs(&buf1, &buf2, ++i);
|
|
|
|
|
} else if (skip_prefix(s, buf2.buf, &next)) {
|
|
|
|
|
off = (s > start + 1 && s[-2] == '\n') ? 1 : 0;
|
|
|
|
|
copy_lines(msg, start, s - start - off);
|
|
|
|
|
start = s - off;
|
|
|
|
|
s = next;
|
|
|
|
|
copy_lines = strbuf_add;
|
|
|
|
|
update_comment_bufs(&buf1, &buf2, ++i);
|
|
|
|
|
} else {
|
|
|
|
|
s = strchr(s, '\n');
|
|
|
|
|
if (s)
|
|
|
|
|
s++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
copy_lines(msg, start, orig_msg_len - (start - orig_msg));
|
|
|
|
|
free(orig_msg);
|
|
|
|
|
strbuf_release(&buf1);
|
|
|
|
|
strbuf_release(&buf2);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int append_squash_message(struct strbuf *buf, const char *body,
|
|
|
|
|
enum todo_command command, struct replay_opts *opts,
|
2021-02-09 03:25:19 +08:00
|
|
|
unsigned flag)
|
2021-01-30 02:20:47 +08:00
|
|
|
{
|
|
|
|
|
const char *fixup_msg;
|
|
|
|
|
size_t commented_len = 0, fixup_off;
|
|
|
|
|
/*
|
|
|
|
|
* amend is non-interactive and not normally used with fixup!
|
|
|
|
|
* or squash! commits, so only comment out those subjects when
|
|
|
|
|
* squashing commit messages.
|
|
|
|
|
*/
|
|
|
|
|
if (starts_with(body, "amend!") ||
|
|
|
|
|
((command == TODO_SQUASH || seen_squash(opts)) &&
|
|
|
|
|
(starts_with(body, "squash!") || starts_with(body, "fixup!"))))
|
2021-03-15 15:54:31 +08:00
|
|
|
commented_len = commit_subject_length(body);
|
2021-01-30 02:20:47 +08:00
|
|
|
|
2021-01-19 15:40:57 +08:00
|
|
|
strbuf_addf(buf, "\n%c ", comment_line_char);
|
2021-01-30 02:20:46 +08:00
|
|
|
strbuf_addf(buf, _(nth_commit_msg_fmt),
|
2021-01-19 15:40:57 +08:00
|
|
|
++opts->current_fixup_count + 1);
|
|
|
|
|
strbuf_addstr(buf, "\n\n");
|
2021-01-30 02:20:44 +08:00
|
|
|
strbuf_add_commented_lines(buf, body, commented_len);
|
2021-01-30 02:20:47 +08:00
|
|
|
/* buf->buf may be reallocated so store an offset into the buffer */
|
|
|
|
|
fixup_off = buf->len;
|
2021-01-30 02:20:44 +08:00
|
|
|
strbuf_addstr(buf, body + commented_len);
|
2021-01-30 02:20:47 +08:00
|
|
|
|
|
|
|
|
/* fixup -C after squash behaves like squash */
|
2021-02-09 03:25:20 +08:00
|
|
|
if (is_fixup_flag(command, flag) && !seen_squash(opts)) {
|
2021-01-30 02:20:47 +08:00
|
|
|
/*
|
|
|
|
|
* We're replacing the commit message so we need to
|
|
|
|
|
* append the Signed-off-by: trailer if the user
|
|
|
|
|
* requested '--signoff'.
|
|
|
|
|
*/
|
|
|
|
|
if (opts->signoff)
|
|
|
|
|
append_signoff(buf, 0, 0);
|
|
|
|
|
|
|
|
|
|
if ((command == TODO_FIXUP) &&
|
|
|
|
|
(flag & TODO_REPLACE_FIXUP_MSG) &&
|
|
|
|
|
(file_exists(rebase_path_fixup_msg()) ||
|
|
|
|
|
!file_exists(rebase_path_squash_msg()))) {
|
|
|
|
|
fixup_msg = skip_blank_lines(buf->buf + fixup_off);
|
|
|
|
|
if (write_message(fixup_msg, strlen(fixup_msg),
|
|
|
|
|
rebase_path_fixup_msg(), 0) < 0)
|
|
|
|
|
return error(_("cannot write '%s'"),
|
|
|
|
|
rebase_path_fixup_msg());
|
|
|
|
|
} else {
|
|
|
|
|
unlink(rebase_path_fixup_msg());
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
unlink(rebase_path_fixup_msg());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
2021-01-19 15:40:57 +08:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
static int update_squash_messages(struct repository *r,
|
|
|
|
|
enum todo_command command,
|
|
|
|
|
struct commit *commit,
|
2021-01-30 02:20:47 +08:00
|
|
|
struct replay_opts *opts,
|
2021-02-09 03:25:19 +08:00
|
|
|
unsigned flag)
|
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;
|
2021-01-30 02:20:47 +08:00
|
|
|
int res = 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
|
|
|
const char *message, *body;
|
2019-11-08 17:43:48 +08:00
|
|
|
const char *encoding = get_commit_output_encoding();
|
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 (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);
|
2021-01-30 02:20:46 +08:00
|
|
|
strbuf_addf(&header, _(combined_commit_msg_fmt),
|
2018-04-28 04:48:21 +08:00
|
|
|
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);
|
2021-02-09 03:25:20 +08:00
|
|
|
if (is_fixup_flag(command, flag) && !seen_squash(opts))
|
2021-01-30 02:20:47 +08:00
|
|
|
update_squash_message_for_fixup(&buf);
|
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
|
|
|
} 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"));
|
2019-11-08 17:43:48 +08:00
|
|
|
if (!(head_message = logmsg_reencode(head_commit, NULL, encoding)))
|
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's commit message"));
|
|
|
|
|
|
|
|
|
|
find_commit_subject(head_message, &body);
|
2021-01-30 02:20:47 +08:00
|
|
|
if (command == TODO_FIXUP && !flag && write_message(body, strlen(body),
|
2021-01-19 15:40:56 +08:00
|
|
|
rebase_path_fixup_msg(), 0) < 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
|
|
|
unuse_commit_buffer(head_commit, head_message);
|
2021-01-19 15:40:56 +08:00
|
|
|
return error(_("cannot write '%s'"), rebase_path_fixup_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
|
|
|
}
|
|
|
|
|
strbuf_addf(&buf, "%c ", comment_line_char);
|
2021-01-30 02:20:46 +08:00
|
|
|
strbuf_addf(&buf, _(combined_commit_msg_fmt), 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);
|
2021-02-09 03:25:20 +08:00
|
|
|
strbuf_addstr(&buf, is_fixup_flag(command, flag) ?
|
2021-01-30 02:20:47 +08:00
|
|
|
_(skip_first_commit_msg_str) :
|
|
|
|
|
_(first_commit_msg_str));
|
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");
|
2021-02-09 03:25:20 +08:00
|
|
|
if (is_fixup_flag(command, flag))
|
2021-01-30 02:20:47 +08:00
|
|
|
strbuf_add_commented_lines(&buf, body, strlen(body));
|
|
|
|
|
else
|
|
|
|
|
strbuf_addstr(&buf, body);
|
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
|
|
|
|
|
|
|
|
unuse_commit_buffer(head_commit, head_message);
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-08 17:43:48 +08:00
|
|
|
if (!(message = logmsg_reencode(commit, NULL, encoding)))
|
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 commit message of %s"),
|
|
|
|
|
oid_to_hex(&commit->object.oid));
|
|
|
|
|
find_commit_subject(message, &body);
|
|
|
|
|
|
2021-02-09 03:25:20 +08:00
|
|
|
if (command == TODO_SQUASH || is_fixup_flag(command, flag)) {
|
2021-01-30 02:20:47 +08:00
|
|
|
res = append_squash_message(&buf, body, command, opts, flag);
|
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
|
|
|
} else if (command == TODO_FIXUP) {
|
|
|
|
|
strbuf_addf(&buf, "\n%c ", comment_line_char);
|
2021-01-30 02:20:46 +08:00
|
|
|
strbuf_addf(&buf, _(skip_nth_commit_msg_fmt),
|
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);
|
|
|
|
|
|
2021-01-30 02:20:47 +08:00
|
|
|
if (!res)
|
|
|
|
|
res = write_message(buf.buf, buf.len, rebase_path_squash_msg(),
|
|
|
|
|
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
|
|
|
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();
|
|
|
|
|
}
|
|
|
|
|
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
static int should_edit(struct replay_opts *opts) {
|
|
|
|
|
if (opts->edit < 0)
|
|
|
|
|
/*
|
|
|
|
|
* Note that we only handle the case of non-conflicted
|
|
|
|
|
* commits; continue_single_pick() handles the conflicted
|
|
|
|
|
* commits itself instead of calling this function.
|
|
|
|
|
*/
|
|
|
|
|
return (opts->action == REPLAY_REVERT && isatty(0)) ? 1 : 0;
|
|
|
|
|
return opts->edit;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 13:48:56 +08:00
|
|
|
static int do_pick_commit(struct repository *r,
|
2021-01-30 02:20:45 +08:00
|
|
|
struct todo_item *item,
|
2018-11-10 13:48:56 +08:00
|
|
|
struct replay_opts *opts,
|
2019-08-19 17:18:22 +08:00
|
|
|
int final_fixup, int *check_todo)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
unsigned int flags = should_edit(opts) ? EDIT_MSG : 0;
|
|
|
|
|
const char *msg_file = should_edit(opts) ? 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;
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
int res, unborn = 0, reword = 0, allow, drop_commit;
|
2021-01-30 02:20:45 +08:00
|
|
|
enum todo_command command = item->command;
|
|
|
|
|
struct commit *commit = item->commit;
|
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
|
2021-08-05 07:50:54 +08:00
|
|
|
* that represents the "current" state for the merge machinery
|
2012-01-12 02:15:57 +08:00
|
|
|
* 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;
|
2019-08-19 17:18:21 +08:00
|
|
|
reword = 1;
|
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)
|
2019-08-19 17:18:21 +08:00
|
|
|
reword = 1;
|
2017-01-02 23:28:00 +08:00
|
|
|
else if (is_fixup(command)) {
|
2021-01-30 02:20:47 +08:00
|
|
|
if (update_squash_messages(r, command, commit,
|
|
|
|
|
opts, item->flags))
|
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())) {
|
2021-01-29 00:16:42 +08:00
|
|
|
flags |= VERBATIM_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;
|
2020-11-03 07:45:34 +08:00
|
|
|
else if (!opts->strategy ||
|
|
|
|
|
!strcmp(opts->strategy, "recursive") ||
|
|
|
|
|
!strcmp(opts->strategy, "ort") ||
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2019-12-07 00:06:09 +08:00
|
|
|
if ((command == TODO_PICK || command == TODO_REWORD ||
|
|
|
|
|
command == TODO_EDIT) && !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
|
|
|
}
|
|
|
|
|
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
drop_commit = 0;
|
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;
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
} else if (allow == 1) {
|
2017-03-24 00:07:11 +08:00
|
|
|
flags |= ALLOW_EMPTY;
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
} else if (allow == 2) {
|
|
|
|
|
drop_commit = 1;
|
2020-08-22 00:59:35 +08:00
|
|
|
refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
|
|
|
|
|
NULL, 0);
|
2020-03-11 23:30:22 +08:00
|
|
|
unlink(git_path_merge_msg(r));
|
2021-03-20 08:03:52 +08:00
|
|
|
unlink(git_path_auto_merge(r));
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
fprintf(stderr,
|
|
|
|
|
_("dropping %s %s -- patch contents already upstream\n"),
|
|
|
|
|
oid_to_hex(&commit->object.oid), msg.subject);
|
|
|
|
|
} /* else allow == 0 and there's nothing special to do */
|
|
|
|
|
if (!opts->no_commit && !drop_commit) {
|
2017-11-24 19:07:57 +08:00
|
|
|
if (author || command == TODO_REVERT || (flags & AMEND_MSG))
|
2019-12-07 00:06:12 +08:00
|
|
|
res = do_commit(r, msg_file, author, opts, flags,
|
|
|
|
|
commit? &commit->object.oid : NULL);
|
2017-11-24 19:07:57 +08:00
|
|
|
else
|
|
|
|
|
res = error(_("unable to parse commit author"));
|
2019-08-19 17:18:22 +08:00
|
|
|
*check_todo = !!(flags & EDIT_MSG);
|
|
|
|
|
if (!res && reword) {
|
2019-08-19 17:18:21 +08:00
|
|
|
fast_forward_edit:
|
2020-09-30 20:29:31 +08:00
|
|
|
res = run_git_commit(NULL, opts, EDIT_MSG |
|
2019-08-19 17:18:21 +08:00
|
|
|
VERIFY_MSG | AMEND_MSG |
|
|
|
|
|
(flags & ALLOW_EMPTY));
|
2019-08-19 17:18:22 +08:00
|
|
|
*check_todo = 1;
|
|
|
|
|
}
|
2017-11-24 19:07:57 +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
|
|
|
|
2019-08-19 17:18:21 +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 (!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);
|
2021-09-08 19:24:00 +08:00
|
|
|
|
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
|
|
|
}
|
2021-09-08 19:24:00 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we are resolving merges in any way other than "ort", then
|
|
|
|
|
* expand the sparse index.
|
|
|
|
|
*/
|
|
|
|
|
if (opts->strategy && strcmp(opts->strategy, "ort"))
|
|
|
|
|
ensure_full_index(r->index);
|
2016-09-09 22:37:21 +08:00
|
|
|
return 0;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
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);
|
2019-11-25 01:43:28 +08:00
|
|
|
todo_list->total_nr++;
|
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 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;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-30 02:20:47 +08:00
|
|
|
if (item->command == TODO_FIXUP) {
|
|
|
|
|
if (skip_prefix(bol, "-C", &bol) &&
|
|
|
|
|
(*bol == ' ' || *bol == '\t')) {
|
|
|
|
|
bol += strspn(bol, " \t");
|
|
|
|
|
item->flags |= TODO_REPLACE_FIXUP_MSG;
|
|
|
|
|
} else if (skip_prefix(bol, "-c", &bol) &&
|
|
|
|
|
(*bol == ' ' || *bol == '\t')) {
|
|
|
|
|
bol += strspn(bol, " \t");
|
|
|
|
|
item->flags |= TODO_EDIT_FIXUP_MSG;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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);
|
2020-01-23 20:28:17 +08:00
|
|
|
if (status < 0)
|
|
|
|
|
error(_("could not parse '%s'"), bol); /* return later */
|
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)
|
2020-01-23 20:28:17 +08:00
|
|
|
return status;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
item->commit = lookup_commit_reference(r, &commit_oid);
|
2020-01-23 20:28:17 +08:00
|
|
|
return item->commit ? 0 : -1;
|
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;
|
|
|
|
|
|
2020-08-22 00:59:35 +08:00
|
|
|
if (refs_ref_exists(get_main_ref_store(r), "CHERRY_PICK_HEAD")) {
|
|
|
|
|
if (!refs_delete_ref(get_main_ref_store(r), "",
|
|
|
|
|
"CHERRY_PICK_HEAD", NULL, 0) &&
|
|
|
|
|
verbose)
|
2019-07-10 06:25:44 +08:00
|
|
|
warning(_("cancelling a cherry picking in progress"));
|
2019-04-16 18:18:41 +08:00
|
|
|
opts.action = REPLAY_PICK;
|
|
|
|
|
need_cleanup = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-22 00:59:37 +08:00
|
|
|
if (refs_ref_exists(get_main_ref_store(r), "REVERT_HEAD")) {
|
|
|
|
|
if (!refs_delete_ref(get_main_ref_store(r), "", "REVERT_HEAD",
|
|
|
|
|
NULL, 0) &&
|
|
|
|
|
verbose)
|
2019-07-10 06:25:44 +08:00
|
|
|
warning(_("cancelling a revert in progress"));
|
2019-04-16 18:18:41 +08:00
|
|
|
opts.action = REPLAY_REVERT;
|
|
|
|
|
need_cleanup = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-20 08:03:52 +08:00
|
|
|
unlink(git_path_auto_merge(r));
|
|
|
|
|
|
2019-04-16 18:18:41 +08:00
|
|
|
if (!need_cleanup)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (!have_finished_the_last_pick())
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
sequencer_remove_state(&opts);
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-25 01:43:30 +08:00
|
|
|
static void todo_list_write_total_nr(struct todo_list *todo_list)
|
|
|
|
|
{
|
|
|
|
|
FILE *f = fopen_or_warn(rebase_path_msgtotal(), "w");
|
|
|
|
|
|
|
|
|
|
if (f) {
|
|
|
|
|
fprintf(f, "%d\n", todo_list->total_nr);
|
|
|
|
|
fclose(f);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
{
|
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
|
|
|
|
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;
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2019-11-25 01:43:30 +08:00
|
|
|
todo_list_write_total_nr(todo_list);
|
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;
|
2020-04-04 09:11:16 +08:00
|
|
|
int ret = 0;
|
2016-10-21 20:25:12 +08:00
|
|
|
|
2020-04-07 22:27:52 +08:00
|
|
|
if (read_oneliner(&buf, rebase_path_gpg_sign_opt(),
|
|
|
|
|
READ_ONELINER_SKIP_IF_EMPTY)) {
|
2016-10-21 20:25:12 +08:00
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:27:52 +08:00
|
|
|
if (read_oneliner(&buf, rebase_path_allow_rerere_autoupdate(),
|
|
|
|
|
READ_ONELINER_SKIP_IF_EMPTY)) {
|
2017-08-02 18:44:17 +08:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 01:40:02 +08:00
|
|
|
if (file_exists(rebase_path_cdate_is_adate())) {
|
|
|
|
|
opts->allow_ff = 0;
|
|
|
|
|
opts->committer_date_is_author_date = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 01:40:03 +08:00
|
|
|
if (file_exists(rebase_path_ignore_date())) {
|
|
|
|
|
opts->allow_ff = 0;
|
|
|
|
|
opts->ignore_date = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-11 03:04:58 +08:00
|
|
|
if (file_exists(rebase_path_reschedule_failed_exec()))
|
|
|
|
|
opts->reschedule_failed_exec = 1;
|
2021-04-09 16:01:38 +08:00
|
|
|
else if (file_exists(rebase_path_no_reschedule_failed_exec()))
|
|
|
|
|
opts->reschedule_failed_exec = 0;
|
2018-12-11 03:04:58 +08:00
|
|
|
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
if (file_exists(rebase_path_drop_redundant_commits()))
|
|
|
|
|
opts->drop_redundant_commits = 1;
|
|
|
|
|
|
|
|
|
|
if (file_exists(rebase_path_keep_redundant_commits()))
|
|
|
|
|
opts->keep_redundant_commits = 1;
|
|
|
|
|
|
2017-01-02 23:28:30 +08:00
|
|
|
read_strategy_opts(opts, &buf);
|
2020-04-04 09:11:16 +08:00
|
|
|
strbuf_reset(&buf);
|
2017-01-02 23:28:30 +08:00
|
|
|
|
2018-04-28 04:48:21 +08:00
|
|
|
if (read_oneliner(&opts->current_fixups,
|
2020-04-07 22:27:52 +08:00
|
|
|
rebase_path_current_fixups(),
|
|
|
|
|
READ_ONELINER_SKIP_IF_EMPTY)) {
|
2018-04-28 04:48:21 +08:00
|
|
|
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)) {
|
2020-10-22 06:03:53 +08:00
|
|
|
if (get_oid_committish(buf.buf, &opts->squash_onto) < 0) {
|
2020-04-04 09:11:16 +08:00
|
|
|
ret = error(_("unusable squash-onto"));
|
|
|
|
|
goto done_rebase_i;
|
|
|
|
|
}
|
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
|
|
|
opts->have_squash_onto = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-04 09:11:16 +08:00
|
|
|
done_rebase_i:
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
return ret;
|
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,
|
2020-11-04 23:29:39 +08:00
|
|
|
struct commit *onto, const struct object_id *orig_head)
|
2018-08-28 20:10:40 +08:00
|
|
|
{
|
|
|
|
|
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)
|
2020-11-04 23:29:39 +08:00
|
|
|
write_file(rebase_path_orig_head(), "%s\n",
|
|
|
|
|
oid_to_hex(orig_head));
|
2018-08-28 20:10:40 +08:00
|
|
|
|
2020-02-16 05:36:27 +08:00
|
|
|
if (opts->quiet)
|
|
|
|
|
write_file(rebase_path_quiet(), "%s", "");
|
2018-08-28 20:10:40 +08:00
|
|
|
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");
|
rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design. This commit addresses
another such corner case: commits which "become empty".
A careful reader may note that there are two types of commits which would
become empty due to a rebase:
* [clean cherry-pick] Commits which are clean cherry-picks of upstream
commits, as determined by `git log --cherry-mark ...`. Re-applying
these commits would result in an empty set of changes and a
duplicative commit message; i.e. these are commits that have
"already been applied" upstream.
* [become empty] Commits which are not empty to start, are not clean
cherry-picks of upstream commits, but which still become empty after
being rebased. This happens e.g. when a commit has changes which
are a strict subset of the changes in an upstream commit, or when
the changes of a commit can be found spread across or among several
upstream commits.
Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.
When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes. Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical). As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around. All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.
For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case. Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes. Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way. As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.
Junio commented on the "become-empty" types of commits as follows[1]:
WRT a change that ends up being empty (as opposed to a change that
is empty from the beginning), I'd think that the current behaviour
is desireable one. "am" based rebase is solely to transplant an
existing history and want to stop much less than "interactive" one
whose purpose is to polish a series before making it publishable,
and asking for confirmation ("this has become empty--do you want to
drop it?") is more appropriate from the workflow point of view.
[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/
I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases. Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.
Introduce a new command line flag for selecting the desired behavior:
--empty={drop,keep,ask}
with the definitions:
drop: drop commits which become empty
keep: keep commits which become empty
ask: provide the user a chance to interact and pick what to do with
commits which become empty on a case-by-case basis
In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
explicitly interactive: ask
otherwise: drop
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:25 +08:00
|
|
|
if (opts->drop_redundant_commits)
|
|
|
|
|
write_file(rebase_path_drop_redundant_commits(), "%s", "");
|
|
|
|
|
if (opts->keep_redundant_commits)
|
|
|
|
|
write_file(rebase_path_keep_redundant_commits(), "%s", "");
|
2020-08-18 01:40:02 +08:00
|
|
|
if (opts->committer_date_is_author_date)
|
|
|
|
|
write_file(rebase_path_cdate_is_adate(), "%s", "");
|
2020-08-18 01:40:03 +08:00
|
|
|
if (opts->ignore_date)
|
|
|
|
|
write_file(rebase_path_ignore_date(), "%s", "");
|
2018-12-11 03:04:58 +08:00
|
|
|
if (opts->reschedule_failed_exec)
|
|
|
|
|
write_file(rebase_path_reschedule_failed_exec(), "%s", "");
|
2021-04-09 16:01:38 +08:00
|
|
|
else
|
|
|
|
|
write_file(rebase_path_no_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;
|
2019-11-08 17:43:47 +08:00
|
|
|
const char *encoding;
|
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
|
|
|
|
2019-11-08 17:43:47 +08:00
|
|
|
encoding = get_log_output_encoding();
|
|
|
|
|
|
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);
|
2019-11-08 17:43:47 +08:00
|
|
|
const char *commit_buffer = logmsg_reencode(commit, NULL, encoding);
|
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 *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;
|
2020-08-22 00:59:35 +08:00
|
|
|
unsigned int advise_skip =
|
2020-08-22 00:59:37 +08:00
|
|
|
refs_ref_exists(get_main_ref_store(r), "REVERT_HEAD") ||
|
2020-08-22 00:59:35 +08:00
|
|
|
refs_ref_exists(get_main_ref_store(r), "CHERRY_PICK_HEAD");
|
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);
|
2021-08-23 18:44:00 +08:00
|
|
|
if (advice_enabled(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;
|
2020-07-29 04:25:12 +08:00
|
|
|
struct strvec argv = STRVEC_INIT;
|
2016-12-08 05:51:32 +08:00
|
|
|
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_pushl(&argv, "reset", "--merge", NULL);
|
2019-07-02 17:11:27 +08:00
|
|
|
|
|
|
|
|
if (!is_null_oid(oid))
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&argv, oid_to_hex(oid));
|
2016-12-08 05:51:32 +08:00
|
|
|
|
2020-07-29 08:37:20 +08:00
|
|
|
ret = run_command_v_opt(argv.v, RUN_GIT_CMD);
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_clear(&argv);
|
2019-07-02 17:11:27 +08:00
|
|
|
|
|
|
|
|
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
|
|
|
|
2020-08-22 00:59:35 +08:00
|
|
|
if (!refs_ref_exists(get_main_ref_store(r), "CHERRY_PICK_HEAD") &&
|
2020-08-22 00:59:37 +08:00
|
|
|
!refs_ref_exists(get_main_ref_store(r), "REVERT_HEAD"))
|
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:
|
2020-08-22 00:59:37 +08:00
|
|
|
if (!refs_ref_exists(get_main_ref_store(r), "REVERT_HEAD")) {
|
2019-07-02 17:11:28 +08:00
|
|
|
if (action != REPLAY_REVERT)
|
|
|
|
|
return error(_("no revert in progress"));
|
|
|
|
|
if (!rollback_is_safe())
|
|
|
|
|
goto give_advice;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case REPLAY_PICK:
|
2020-08-22 00:59:35 +08:00
|
|
|
if (!refs_ref_exists(get_main_ref_store(r),
|
|
|
|
|
"CHERRY_PICK_HEAD")) {
|
2019-07-02 17:11:28 +08:00
|
|
|
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"));
|
|
|
|
|
|
2021-08-23 18:44:00 +08:00
|
|
|
if (advice_enabled(ADVICE_RESOLVE_CONFLICT)) {
|
2019-07-02 17:11:28 +08:00
|
|
|
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");
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
if (opts->edit >= 0)
|
|
|
|
|
res |= git_config_set_in_file_gently(opts_file, "options.edit",
|
|
|
|
|
opts->edit ? "true" : "false");
|
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;
|
2020-09-25 13:49:12 +08:00
|
|
|
const char *subject;
|
|
|
|
|
char hex[GIT_MAX_HEXSZ + 1];
|
2017-01-02 23:26:43 +08:00
|
|
|
int res = 0;
|
|
|
|
|
|
2020-09-25 13:49:12 +08:00
|
|
|
oid_to_hex_r(hex, &commit->object.oid);
|
|
|
|
|
if (write_message(hex, strlen(hex), rebase_path_stopped_sha(), 1) < 0)
|
2017-01-02 23:26:43 +08:00
|
|
|
return -1;
|
2019-12-07 00:06:12 +08:00
|
|
|
res |= write_rebase_head(&commit->object.oid);
|
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)) {
|
2019-11-11 14:03:41 +08:00
|
|
|
const char *encoding = get_commit_output_encoding();
|
|
|
|
|
const char *commit_buffer = logmsg_reencode(commit, NULL, encoding);
|
2017-01-02 23:26:43 +08:00
|
|
|
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
|
|
|
{
|
|
|
|
|
const char *child_argv[] = { NULL, NULL };
|
|
|
|
|
int dirty, status;
|
|
|
|
|
|
2020-03-28 21:05:15 +08:00
|
|
|
fprintf(stderr, _("Executing: %s\n"), command_line);
|
2017-01-02 23:26:47 +08:00
|
|
|
child_argv[0] = command_line;
|
sequencer: do not export GIT_DIR and GIT_WORK_TREE for 'exec'
Commands executed from `git rebase --exec` can give different behavior
from within that environment than they would outside of it, due to the
fact that sequencer.c exports both GIT_DIR and GIT_WORK_TREE. For
example, if the relevant script calls something like
git -C ../otherdir log --format=%H --no-walk
the user may be surprised to find that the command above does not show a
commit hash from ../otherdir, because $GIT_DIR prevents automatic gitdir
detection and makes the -C option useless.
This is a regression in behavior from the original legacy
implemented-in-shell rebase. It is perhaps rare for it to cause
problems in practice, especially since most small problems that were
caused by this area of bugs has been fixed-up in the past in a way that
masked the particular bug observed without fixing the real underlying
problem.
An explanation of how we arrived at the current situation is perhaps
merited. The setting of GIT_DIR and GIT_WORK_TREE done by sequencer.c
arose from a sequence of historical accidents:
* When rebase was implemented as a shell command, it would call
git-sh-setup, which among other things would set GIT_DIR -- but not
export it. This meant that when rebase --exec commands were run via
/bin/sh -c "$COMMAND"
they would not inherit the GIT_DIR setting. The fact that GIT_DIR
was not set in the run $COMMAND is the behavior we'd like to restore.
* When the rebase--helper builtin was introduced to allow incrementally
replacing shell with C code, we had an implementation that was half
shell, half C. In particular, commit 18633e1a22 ("rebase -i: use the
rebase--helper builtin", 2017-02-09) added calls to
exec git rebase--helper ...
which caused rebase--helper to inherit the GIT_DIR environment
variable from the shell. git's setup would change the environment
variable from an absolute path to a relative one (".git"), but would
leave it set. This meant that when rebase --exec commands were run
via
run_command_v_opt(...)
they would inherit the GIT_DIR setting.
* In commit 09d7b6c6fa ("sequencer: pass absolute GIT_DIR to exec
commands", 2017-10-31), it was noted that the GIT_DIR caused problems
with some commands; e.g.
git rebase --exec 'cd subdir && git describe' ...
would have GIT_DIR=.git which was invalid due to the change to the
subdirectory. Instead of questioning why GIT_DIR was set, that commit
instead made sequencer change GIT_DIR to be an absolute path and
explicitly export it via
argv_array_pushf(&child_env, "GIT_DIR=%s", absolute_path(get_git_dir()));
run_command_v_opt_cd_env(..., child_env.argv)
* In commit ab5e67d751 ("sequencer: pass absolute GIT_WORK_TREE to exec
commands", 2018-07-14), it was noted that when GIT_DIR is set but
GIT_WORK_TREE is not, that we do not discover GIT_WORK_TREE but just
assume it is '.'. That is incorrect if trying to run commands from a
subdirectory. However, rather than question why GIT_DIR was set, that
commit instead also added GIT_WORK_TREE to the list of things to
export.
Each of the above problems would have been fixed automatically when
git-rebase became a full builtin, had it not been for the fact that
sequencer.c started exporting GIT_DIR and GIT_WORK_TREE in the interim.
Stop exporting them now.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Johannes Altmanninger <aclopte@gmail.com>
Acked-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04 13:36:59 +08:00
|
|
|
status = run_command_v_opt(child_argv, RUN_USING_SHELL);
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-13 16:05:18 +08:00
|
|
|
__attribute__((format (printf, 2, 3)))
|
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);
|
2020-02-16 05:36:36 +08:00
|
|
|
strbuf_addf(&msg, "rebase (label) '%.*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
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-13 16:05:18 +08:00
|
|
|
__attribute__((format (printf, 3, 4)))
|
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 const char *reflog_message(struct replay_opts *opts,
|
2021-07-10 16:47:28 +08:00
|
|
|
const char *sub_action, const char *fmt, ...)
|
|
|
|
|
{
|
|
|
|
|
va_list ap;
|
|
|
|
|
static struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
char *reflog_action = getenv(GIT_REFLOG_ACTION);
|
|
|
|
|
|
|
|
|
|
va_start(ap, fmt);
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
strbuf_addstr(&buf, reflog_action ? reflog_action : 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;
|
|
|
|
|
}
|
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
|
|
|
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;
|
2021-10-13 21:23:54 +08:00
|
|
|
struct tree_desc desc = { 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
|
|
|
struct tree *tree;
|
2021-10-13 21:23:55 +08:00
|
|
|
struct unpack_trees_options unpack_tree_opts = { 0 };
|
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)) {
|
2021-10-13 21:23:54 +08:00
|
|
|
ret = error(_("could not read '%s'"), ref_name.buf);
|
|
|
|
|
goto cleanup;
|
2018-05-04 07:01:23 +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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
2021-09-28 00:33:43 +08:00
|
|
|
unpack_tree_opts.preserve_ignored = 0; /* FIXME: !overwrite_ignore */
|
2020-03-17 02:05:06 +08:00
|
|
|
init_checkout_metadata(&unpack_tree_opts.meta, name, &oid, NULL);
|
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:26 +08:00
|
|
|
if (repo_read_index_unmerged(r)) {
|
2021-10-13 21:23:54 +08:00
|
|
|
ret = error_resolve_conflict(_(action_name(opts)));
|
|
|
|
|
goto cleanup;
|
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-06-27 17:28:48 +08:00
|
|
|
if (!fill_tree_descriptor(r, &desc, &oid)) {
|
2021-10-13 21:23:54 +08:00
|
|
|
ret = error(_("failed to find tree of %s"), oid_to_hex(&oid));
|
|
|
|
|
goto cleanup;
|
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 (unpack_trees(1, &desc, &unpack_tree_opts)) {
|
2021-10-13 21:23:54 +08:00
|
|
|
ret = -1;
|
|
|
|
|
goto cleanup;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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"));
|
|
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
|
ret = update_ref(reflog_message(opts, "reset", "'%.*s'",
|
|
|
|
|
len, name), "HEAD", &oid,
|
|
|
|
|
NULL, 0, UPDATE_REFS_MSG_ON_ERR);
|
2021-10-13 21:23:54 +08:00
|
|
|
cleanup:
|
|
|
|
|
free((void *)desc.buffer);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
rollback_lock_file(&lock);
|
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(&ref_name);
|
2021-10-13 21:23:55 +08:00
|
|
|
clear_unpack_trees_porcelain(&unpack_tree_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
|
|
|
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,
|
2021-08-20 23:40:35 +08:00
|
|
|
int flags, int *check_todo, struct replay_opts *opts)
|
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
|
|
|
{
|
2021-08-20 23:40:35 +08:00
|
|
|
int run_commit_flags = 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
|
|
|
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;
|
2019-07-31 23:18:47 +08:00
|
|
|
const char *strategy = !opts->xopts_nr &&
|
2020-11-03 07:45:34 +08:00
|
|
|
(!opts->strategy ||
|
|
|
|
|
!strcmp(opts->strategy, "recursive") ||
|
|
|
|
|
!strcmp(opts->strategy, "ort")) ?
|
2019-07-31 23:18:47 +08:00
|
|
|
NULL : opts->strategy;
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-20 23:40:37 +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 &&
|
|
|
|
|
oideq(&commit->parents->item->object.oid,
|
|
|
|
|
&head_commit->object.oid);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If any merge head is different from the original one, we cannot
|
|
|
|
|
* fast-forward.
|
|
|
|
|
*/
|
|
|
|
|
if (can_fast_forward) {
|
|
|
|
|
struct commit_list *p = commit->parents->next;
|
|
|
|
|
|
|
|
|
|
for (j = to_merge; j && p; j = j->next, p = p->next)
|
|
|
|
|
if (!oideq(&j->item->object.oid,
|
|
|
|
|
&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)
|
|
|
|
|
can_fast_forward = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (can_fast_forward) {
|
|
|
|
|
rollback_lock_file(&lock);
|
|
|
|
|
ret = fast_forward_to(r, &commit->object.oid,
|
|
|
|
|
&head_commit->object.oid, 0, opts);
|
|
|
|
|
if (flags & TODO_EDIT_MERGE_MSG)
|
|
|
|
|
goto fast_forward_edit;
|
|
|
|
|
|
|
|
|
|
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) {
|
2019-11-11 14:03:40 +08:00
|
|
|
const char *encoding = get_commit_output_encoding();
|
|
|
|
|
const char *message = logmsg_reencode(commit, NULL, encoding);
|
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
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-31 23:18:47 +08:00
|
|
|
if (strategy || to_merge->next) {
|
2017-12-21 22:52:45 +08:00
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 01:40:02 +08:00
|
|
|
if (opts->committer_date_is_author_date)
|
2020-09-04 03:37:01 +08:00
|
|
|
strvec_pushf(&cmd.env_array, "GIT_COMMITTER_DATE=%s",
|
|
|
|
|
opts->ignore_date ?
|
|
|
|
|
"" :
|
|
|
|
|
author_date_from_env_array(&cmd.env_array));
|
2020-08-18 01:40:03 +08:00
|
|
|
if (opts->ignore_date)
|
2020-09-04 03:37:01 +08:00
|
|
|
strvec_push(&cmd.env_array, "GIT_AUTHOR_DATE=");
|
2020-08-18 01:40:02 +08:00
|
|
|
|
2017-12-21 22:52:45 +08:00
|
|
|
cmd.git_cmd = 1;
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "merge");
|
|
|
|
|
strvec_push(&cmd.args, "-s");
|
2019-07-31 23:18:47 +08:00
|
|
|
if (!strategy)
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "octopus");
|
2019-07-31 23:18:47 +08:00
|
|
|
else {
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, strategy);
|
2019-07-31 23:18:47 +08:00
|
|
|
for (k = 0; k < opts->xopts_nr; k++)
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_pushf(&cmd.args,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29 04:26:31 +08:00
|
|
|
"-X%s", opts->xopts[k]);
|
2019-07-31 23:18:47 +08:00
|
|
|
}
|
2021-08-20 23:40:38 +08:00
|
|
|
if (!(flags & TODO_EDIT_MERGE_MSG))
|
|
|
|
|
strvec_push(&cmd.args, "--no-edit");
|
|
|
|
|
else
|
|
|
|
|
strvec_push(&cmd.args, "--edit");
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "--no-ff");
|
|
|
|
|
strvec_push(&cmd.args, "--no-log");
|
|
|
|
|
strvec_push(&cmd.args, "--no-stat");
|
|
|
|
|
strvec_push(&cmd.args, "-F");
|
|
|
|
|
strvec_push(&cmd.args, git_path_merge_msg(r));
|
2017-12-21 22:52:45 +08:00
|
|
|
if (opts->gpg_sign)
|
2020-10-18 07:15:55 +08:00
|
|
|
strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign);
|
2020-10-18 07:15:56 +08:00
|
|
|
else
|
|
|
|
|
strvec_push(&cmd.args, "--no-gpg-sign");
|
2017-12-21 22:52:45 +08:00
|
|
|
|
|
|
|
|
/* Add the tips to be merged */
|
|
|
|
|
for (j = to_merge; j; j = j->next)
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29 04:26:31 +08:00
|
|
|
oid_to_hex(&j->item->object.oid));
|
2017-12-21 22:52:45 +08:00
|
|
|
|
|
|
|
|
strbuf_release(&ref_name);
|
2020-08-22 00:59:35 +08:00
|
|
|
refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
|
|
|
|
|
NULL, 0);
|
2017-12-21 22:52:45 +08:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-19 04:04:16 +08:00
|
|
|
write_message(oid_to_hex(&merge_commit->object.oid), the_hash_algo->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;
|
|
|
|
|
|
Change default merge backend from recursive to ort
There are a few reasons to switch the default:
* Correctness
* Extensibility
* Performance
I'll provide some summaries about each.
=== Correctness ===
The original impetus for a new merge backend was to fix issues that were
difficult to fix within recursive's design. The success with this goal
is perhaps most easily demonstrated by running the following:
$ git grep -2 KNOWN_FAILURE t/ | grep -A 4 GIT_TEST_MERGE_ALGORITHM
$ git grep test_expect_merge_algorithm.failure.success t/
$ git grep test_expect_merge_algorithm.success.failure t/
In order, these greps show:
* Seven sets of submodule tests (10 total tests) that fail with
recursive but succeed with ort
* 22 other tests that fail with recursive, but succeed with ort
* 0 tests that pass with recursive, but fail with ort
=== Extensibility ===
Being able to perform merges without touching the working tree or index
makes it possible to create new features that were difficult with the
old backend:
* Merging, cherry-picking, rebasing, reverting in bare repositories...
or just on branches that aren't checked out.
* `git diff AUTO_MERGE` -- ability to see what changes the user has
made to resolve conflicts so far (see commit 5291828df8 ("merge-ort:
write $GIT_DIR/AUTO_MERGE whenever we hit a conflict", 2021-03-20)
* A --remerge-diff option for log/show, used to show diffs for merges
that display the difference between what an automatic merge would
have created and what was recorded in the merge. (This option will
often result in an empty diff because many merges are clean, but for
the non-clean ones it will show how conflicts were fixed including
the removal of conflict markers, and also show additional changes
made outside of conflict regions to e.g. fix semantic conflicts.)
* A --remerge-diff-only option for log/show, similar to --remerge-diff
but also showing how cherry-picks or reverts differed from what an
automatic cherry-pick or revert would provide.
The last three have been implemented already (though only one has been
submitted upstream so far; the others were waiting for performance work
to complete), and I still plan to implement the first one.
=== Performance ===
I'll quote from the summary of my final optimization for merge-ort
(while fixing the testcase name from 'no-renames' to 'few-renames'):
Timings
Infinite
merge- merge- Parallelism
recursive recursive of rename merge-ort
v2.30.0 current detection current
---------- --------- ----------- ---------
few-renames: 18.912 s 18.030 s 11.699 s 198.3 ms
mega-renames: 5964.031 s 361.281 s 203.886 s 661.8 ms
just-one-mega: 149.583 s 11.009 s 7.553 s 264.6 ms
Speedup factors
Infinite
merge- merge- Parallelism
recursive recursive of rename
v2.30.0 current detection merge-ort
---------- --------- ----------- ---------
few-renames: 1 1.05 1.6 95
mega-renames: 1 16.5 29 9012
just-one-mega: 1 13.6 20 565
And, for partial clone users:
Factor reduction in number of objects needed
Infinite
merge- merge- Parallelism
recursive recursive of rename
v2.30.0 current detection merge-ort
---------- --------- ----------- ---------
mega-renames: 1 1 1 181.3
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-04 13:38:01 +08:00
|
|
|
if (!opts->strategy || !strcmp(opts->strategy, "ort")) {
|
2020-11-03 07:45:34 +08:00
|
|
|
/*
|
|
|
|
|
* TODO: Should use merge_incore_recursive() and
|
|
|
|
|
* merge_switch_to_result(), skipping the call to
|
|
|
|
|
* merge_switch_to_result() when we don't actually need to
|
|
|
|
|
* update the index and working copy immediately.
|
|
|
|
|
*/
|
|
|
|
|
ret = merge_ort_recursive(&o,
|
|
|
|
|
head_commit, merge_commit, reversed,
|
|
|
|
|
&i);
|
|
|
|
|
} else {
|
|
|
|
|
ret = merge_recursive(&o, head_commit, merge_commit, reversed,
|
|
|
|
|
&i);
|
|
|
|
|
}
|
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 (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).
|
|
|
|
|
*/
|
2020-09-30 20:29:31 +08:00
|
|
|
ret = !!run_git_commit(git_path_merge_msg(r), opts,
|
2018-11-10 13:48:56 +08:00
|
|
|
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
|
|
|
|
2021-08-20 23:40:35 +08:00
|
|
|
if (!ret && flags & TODO_EDIT_MERGE_MSG) {
|
|
|
|
|
fast_forward_edit:
|
|
|
|
|
*check_todo = 1;
|
|
|
|
|
run_commit_flags |= AMEND_MSG | EDIT_MSG | VERIFY_MSG;
|
|
|
|
|
ret = !!run_git_commit(NULL, 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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:28:03 +08:00
|
|
|
void create_autostash(struct repository *r, const char *path,
|
|
|
|
|
const char *default_reflog_action)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
struct lock_file lock_file = LOCK_INIT;
|
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
|
|
fd = repo_hold_locked_index(r, &lock_file, 0);
|
|
|
|
|
refresh_index(r->index, REFRESH_QUIET, NULL, NULL, NULL);
|
|
|
|
|
if (0 <= fd)
|
|
|
|
|
repo_update_index_if_able(r, &lock_file);
|
|
|
|
|
rollback_lock_file(&lock_file);
|
|
|
|
|
|
|
|
|
|
if (has_unstaged_changes(r, 1) ||
|
|
|
|
|
has_uncommitted_changes(r, 1)) {
|
|
|
|
|
struct child_process stash = CHILD_PROCESS_INIT;
|
|
|
|
|
struct object_id oid;
|
|
|
|
|
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_pushl(&stash.args,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29 04:26:31 +08:00
|
|
|
"stash", "create", "autostash", NULL);
|
2020-04-07 22:28:03 +08:00
|
|
|
stash.git_cmd = 1;
|
|
|
|
|
stash.no_stdin = 1;
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
if (capture_command(&stash, &buf, GIT_MAX_HEXSZ))
|
|
|
|
|
die(_("Cannot autostash"));
|
|
|
|
|
strbuf_trim_trailing_newline(&buf);
|
|
|
|
|
if (get_oid(buf.buf, &oid))
|
|
|
|
|
die(_("Unexpected stash response: '%s'"),
|
|
|
|
|
buf.buf);
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
|
strbuf_add_unique_abbrev(&buf, &oid, DEFAULT_ABBREV);
|
|
|
|
|
|
|
|
|
|
if (safe_create_leading_directories_const(path))
|
|
|
|
|
die(_("Could not create directory for '%s'"),
|
|
|
|
|
path);
|
|
|
|
|
write_file(path, "%s", oid_to_hex(&oid));
|
|
|
|
|
printf(_("Created autostash: %s\n"), buf.buf);
|
|
|
|
|
if (reset_head(r, NULL, "reset --hard",
|
|
|
|
|
NULL, RESET_HEAD_HARD, NULL, NULL,
|
|
|
|
|
default_reflog_action) < 0)
|
|
|
|
|
die(_("could not reset --hard"));
|
|
|
|
|
|
|
|
|
|
if (discard_index(r->index) < 0 ||
|
|
|
|
|
repo_read_index(r) < 0)
|
|
|
|
|
die(_("could not read index"));
|
|
|
|
|
}
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:28:06 +08:00
|
|
|
static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply)
|
2017-01-02 23:28:27 +08:00
|
|
|
{
|
|
|
|
|
struct child_process child = CHILD_PROCESS_INIT;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
2020-04-07 22:28:05 +08:00
|
|
|
if (attempt_apply) {
|
|
|
|
|
child.git_cmd = 1;
|
|
|
|
|
child.no_stdout = 1;
|
|
|
|
|
child.no_stderr = 1;
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&child.args, "stash");
|
|
|
|
|
strvec_push(&child.args, "apply");
|
|
|
|
|
strvec_push(&child.args, stash_oid);
|
2020-04-07 22:28:05 +08:00
|
|
|
ret = run_command(&child);
|
2017-01-02 23:28:27 +08:00
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:28:05 +08:00
|
|
|
if (attempt_apply && !ret)
|
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;
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&store.args, "stash");
|
|
|
|
|
strvec_push(&store.args, "store");
|
|
|
|
|
strvec_push(&store.args, "-m");
|
|
|
|
|
strvec_push(&store.args, "autostash");
|
|
|
|
|
strvec_push(&store.args, "-q");
|
|
|
|
|
strvec_push(&store.args, stash_oid);
|
2017-01-02 23:28:27 +08:00
|
|
|
if (run_command(&store))
|
2020-04-07 22:28:06 +08:00
|
|
|
ret = error(_("cannot store %s"), stash_oid);
|
2017-01-02 23:28:27 +08:00
|
|
|
else
|
2017-06-20 01:56:02 +08:00
|
|
|
fprintf(stderr,
|
2020-04-07 22:28:05 +08:00
|
|
|
_("%s\n"
|
2017-06-20 01:56:02 +08:00
|
|
|
"Your changes are safe in the stash.\n"
|
|
|
|
|
"You can run \"git stash pop\" or"
|
2020-04-07 22:28:05 +08:00
|
|
|
" \"git stash drop\" at any time.\n"),
|
|
|
|
|
attempt_apply ?
|
|
|
|
|
_("Applying autostash resulted in conflicts.") :
|
|
|
|
|
_("Autostash exists; creating a new stash entry."));
|
2017-01-02 23:28:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:28:06 +08:00
|
|
|
static int apply_save_autostash(const char *path, int attempt_apply)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf stash_oid = STRBUF_INIT;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
if (!read_oneliner(&stash_oid, path,
|
|
|
|
|
READ_ONELINER_SKIP_IF_EMPTY)) {
|
|
|
|
|
strbuf_release(&stash_oid);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
strbuf_trim(&stash_oid);
|
|
|
|
|
|
|
|
|
|
ret = apply_save_autostash_oid(stash_oid.buf, attempt_apply);
|
|
|
|
|
|
2020-04-07 22:28:04 +08:00
|
|
|
unlink(path);
|
2020-04-07 22:27:57 +08:00
|
|
|
strbuf_release(&stash_oid);
|
2017-01-02 23:28:27 +08:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:28:05 +08:00
|
|
|
int save_autostash(const char *path)
|
|
|
|
|
{
|
|
|
|
|
return apply_save_autostash(path, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int apply_autostash(const char *path)
|
|
|
|
|
{
|
|
|
|
|
return apply_save_autostash(path, 1);
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-07 22:28:06 +08:00
|
|
|
int apply_autostash_oid(const char *stash_oid)
|
|
|
|
|
{
|
|
|
|
|
return apply_save_autostash_oid(stash_oid, 1);
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
|
2022-01-26 09:43:45 +08:00
|
|
|
if (startup_info->original_cwd) {
|
2021-12-09 13:08:31 +08:00
|
|
|
cmd.dir = startup_info->original_cwd;
|
2022-01-26 09:43:45 +08:00
|
|
|
strvec_pushf(&cmd.env_array, "%s=%s",
|
|
|
|
|
GIT_WORK_TREE_ENVIRONMENT, r->worktree);
|
|
|
|
|
}
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&cmd.args, "checkout");
|
|
|
|
|
strvec_push(&cmd.args, commit);
|
|
|
|
|
strvec_pushf(&cmd.env_array, GIT_REFLOG_ACTION "=%s", action);
|
2018-08-11 00:51:33 +08:00
|
|
|
|
|
|
|
|
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
|
|
|
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,
|
2020-11-04 23:29:38 +08:00
|
|
|
const struct object_id *orig_head)
|
2018-08-11 00:51:34 +08:00
|
|
|
{
|
|
|
|
|
const char *action = reflog_message(opts, "start", "checkout %s", onto_name);
|
|
|
|
|
|
2019-04-17 22:30:39 +08:00
|
|
|
if (run_git_checkout(r, opts, oid_to_hex(onto), action)) {
|
2020-04-07 22:27:56 +08:00
|
|
|
apply_autostash(rebase_path_autostash());
|
2018-08-11 00:51:34 +08:00
|
|
|
sequencer_remove_state(opts);
|
|
|
|
|
return error(_("could not detach HEAD"));
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-04 23:29:38 +08:00
|
|
|
return update_ref(NULL, "ORIG_HEAD", orig_head, NULL, 0, UPDATE_REFS_MSG_ON_ERR);
|
2018-08-11 00:51:34 +08:00
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-23 23:26:20 +08:00
|
|
|
static int reread_todo_if_changed(struct repository *r,
|
|
|
|
|
struct todo_list *todo_list,
|
|
|
|
|
struct replay_opts *opts)
|
|
|
|
|
{
|
2021-09-23 23:26:21 +08:00
|
|
|
int offset;
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2021-09-23 23:26:20 +08:00
|
|
|
|
2021-09-23 23:26:21 +08:00
|
|
|
if (strbuf_read_file_or_whine(&buf, get_todo_path(opts)) < 0)
|
|
|
|
|
return -1;
|
|
|
|
|
offset = get_item_line_offset(todo_list, todo_list->current + 1);
|
|
|
|
|
if (buf.len != todo_list->buf.len - offset ||
|
|
|
|
|
memcmp(buf.buf, todo_list->buf.buf + offset, buf.len)) {
|
2021-09-23 23:26:20 +08:00
|
|
|
/* Reread the todo file if it has changed. */
|
|
|
|
|
todo_list_release(todo_list);
|
|
|
|
|
if (read_populate_todo(r, todo_list, opts))
|
|
|
|
|
return -1; /* message was printed */
|
|
|
|
|
/* `current` will be incremented on return */
|
|
|
|
|
todo_list->current = -1;
|
|
|
|
|
}
|
2021-09-23 23:26:21 +08:00
|
|
|
strbuf_release(&buf);
|
2021-09-23 23:26:20 +08:00
|
|
|
|
|
|
|
|
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;
|
2020-04-08 00:59:23 +08:00
|
|
|
char *prev_reflog_action;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2020-04-08 00:59:23 +08:00
|
|
|
/* Note that 0 for 3rd parameter of setenv means set only if not set */
|
2012-01-12 02:15:57 +08:00
|
|
|
setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
|
2020-04-08 00:59:23 +08:00
|
|
|
prev_reflog_action = xstrdup(getenv(GIT_REFLOG_ACTION));
|
2012-01-12 02:15:57 +08:00
|
|
|
if (opts->allow_ff)
|
|
|
|
|
assert(!(opts->signoff || opts->no_commit ||
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
opts->record_origin || should_edit(opts) ||
|
2020-08-18 01:40:03 +08:00
|
|
|
opts->committer_date_is_author_date ||
|
|
|
|
|
opts->ignore_date));
|
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);
|
2019-08-19 17:18:22 +08:00
|
|
|
int check_todo = 0;
|
2019-01-29 23:01:46 +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
|
|
|
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)
|
2020-03-28 21:05:15 +08:00
|
|
|
fprintf(stderr, _("Rebasing (%d/%d)%s"),
|
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
|
|
|
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));
|
2021-03-20 08:03:52 +08:00
|
|
|
unlink(git_path_auto_merge(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))
|
2020-04-08 00:59:23 +08:00
|
|
|
setenv(GIT_REFLOG_ACTION, reflog_message(opts,
|
2017-01-02 23:28:13 +08:00
|
|
|
command_to_string(item->command), NULL),
|
|
|
|
|
1);
|
2021-01-30 02:20:45 +08:00
|
|
|
res = do_pick_commit(r, item, opts,
|
|
|
|
|
is_final_fixup(todo_list),
|
2019-08-19 17:18:22 +08:00
|
|
|
&check_todo);
|
2020-04-08 00:59:23 +08:00
|
|
|
if (is_rebase_i(opts))
|
|
|
|
|
setenv(GIT_REFLOG_ACTION, prev_reflog_action, 1);
|
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;
|
|
|
|
|
|
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;
|
2017-04-27 03:17:40 +08:00
|
|
|
}
|
2019-08-19 17:18:22 +08:00
|
|
|
check_todo = 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) {
|
2021-08-20 23:40:35 +08:00
|
|
|
if ((res = do_merge(r, item->commit, arg, item->arg_len,
|
|
|
|
|
item->flags, &check_todo, opts)) < 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
|
|
|
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);
|
2021-09-23 23:26:20 +08:00
|
|
|
} else if (is_rebase_i(opts) && check_todo && !res &&
|
|
|
|
|
reread_todo_if_changed(r, todo_list, opts)) {
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
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;
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&child.args, "notes");
|
|
|
|
|
strvec_push(&child.args, "copy");
|
|
|
|
|
strvec_push(&child.args, "--for-rewrite=rebase");
|
2017-01-02 23:28:16 +08:00
|
|
|
/* 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";
|
2020-07-29 04:25:12 +08:00
|
|
|
strvec_push(&hook.args, post_rewrite_hook);
|
|
|
|
|
strvec_push(&hook.args, "rebase");
|
2017-01-02 23:28:23 +08:00
|
|
|
/* we don't care if this hook failed */
|
|
|
|
|
run_command(&hook);
|
|
|
|
|
}
|
2017-01-02 23:28:16 +08:00
|
|
|
}
|
2020-04-07 22:27:56 +08:00
|
|
|
apply_autostash(rebase_path_autostash());
|
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,
|
2020-03-28 21:05:15 +08:00
|
|
|
_("Successfully rebased and updated %s.\n"),
|
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
|
|
|
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
|
|
|
}
|
|
|
|
|
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
static int continue_single_pick(struct repository *r, struct replay_opts *opts)
|
2012-01-12 02:15:57 +08:00
|
|
|
{
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
struct strvec argv = STRVEC_INIT;
|
|
|
|
|
int ret;
|
2012-01-12 02:15:57 +08:00
|
|
|
|
2020-08-22 00:59:35 +08:00
|
|
|
if (!refs_ref_exists(get_main_ref_store(r), "CHERRY_PICK_HEAD") &&
|
2020-08-22 00:59:37 +08:00
|
|
|
!refs_ref_exists(get_main_ref_store(r), "REVERT_HEAD"))
|
2012-01-12 02:15:57 +08:00
|
|
|
return error(_("no cherry-pick or revert in progress"));
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
|
|
|
|
|
strvec_push(&argv, "commit");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* continue_single_pick() handles the case of recovering from a
|
|
|
|
|
* conflict. should_edit() doesn't handle that case; for a conflict,
|
|
|
|
|
* we want to edit if the user asked for it, or if they didn't specify
|
|
|
|
|
* and stdin is a tty.
|
|
|
|
|
*/
|
|
|
|
|
if (!opts->edit || (opts->edit < 0 && !isatty(0)))
|
|
|
|
|
/*
|
|
|
|
|
* Include --cleanup=strip as well because we don't want the
|
|
|
|
|
* "# Conflicts:" messages.
|
|
|
|
|
*/
|
|
|
|
|
strvec_pushl(&argv, "--no-edit", "--cleanup=strip", NULL);
|
|
|
|
|
|
|
|
|
|
ret = run_command_v_opt(argv.v, RUN_GIT_CMD);
|
|
|
|
|
strvec_clear(&argv);
|
|
|
|
|
return ret;
|
2012-01-12 02:15:57 +08:00
|
|
|
}
|
|
|
|
|
|
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();
|
2019-11-08 17:43:48 +08:00
|
|
|
const char *encoding = get_commit_output_encoding();
|
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
|
|
|
|
2018-11-10 13:48:57 +08:00
|
|
|
if (parse_head(r, &commit) ||
|
2019-11-08 17:43:48 +08:00
|
|
|
!(p = logmsg_reencode(commit, NULL, encoding)) ||
|
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
|
|
|
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) {
|
2020-08-22 00:59:35 +08:00
|
|
|
if (refs_ref_exists(get_main_ref_store(r),
|
|
|
|
|
"CHERRY_PICK_HEAD") &&
|
|
|
|
|
refs_delete_ref(get_main_ref_store(r), "",
|
|
|
|
|
"CHERRY_PICK_HEAD", NULL, 0))
|
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
|
|
|
return error(_("could not remove CHERRY_PICK_HEAD"));
|
2021-08-12 21:42:09 +08:00
|
|
|
if (unlink(git_path_merge_msg(r)) && errno != ENOENT)
|
|
|
|
|
return error_errno(_("could not remove '%s'"),
|
|
|
|
|
git_path_merge_msg(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)
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-30 20:29:31 +08:00
|
|
|
if (run_git_commit(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));
|
2021-03-20 08:03:52 +08:00
|
|
|
unlink(git_path_auto_merge(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;
|
rebase-interactive: warn if commit is dropped with `rebase --edit-todo'
When set to "warn" or "error", `rebase.missingCommitsCheck' would make
`rebase -i' warn if the user removed commits from the todo list to
prevent mistakes. Unfortunately, `rebase --edit-todo' and `rebase
--continue' don't take it into account.
This adds the ability for `rebase --edit-todo' and `rebase --continue'
to check if commits were dropped by the user. As both edit_todo_list()
and complete_action() parse the todo list and check for dropped commits,
the code doing so in the latter is removed to reduce duplication.
`edit_todo_list_advice' is removed from sequencer.c as it is no longer
used there.
This changes when a backup of the todo list is made. Until now, it was
saved only once, before the initial edit. Now, it is also made if the
original todo list has no errors or no dropped commits. Thus, the
backup should be error-free. Without this, sequencer_continue()
(`rebase --continue') could only compare the current todo list against
the original, unedited list. Before this change, this file was only
used by edit_todo_list() and `rebase -p' to create the backup before
the initial edit, and check_todo_list_from_file(), only used by
`rebase -p' to check for dropped commits after its own initial edit.
If the edited list has an error, a file, `dropped', is created to
report the issue. Otherwise, it is deleted. Usually, the edited list
is compared against the list before editing, but if this file exists,
it will be compared to the backup. Also, if the file exists,
sequencer_continue() checks the list for dropped commits. If the
check was performed every time, it would fail when resuming a rebase
after resolving a conflict, as the backup will contain commits that
were picked, but they will not be in the new list. It's safe to
ignore this check if `dropped' does not exist, because that means that
no errors were found at the last edition, so any missing commits here
have already been picked.
Five tests are added to t3404. The tests for
`rebase.missingCommitsCheck = warn' and `rebase.missingCommitsCheck =
error' have a similar structure. First, we start a rebase with an
incorrect command on the first line. Then, we edit the todo list,
removing the first and the last lines. This demonstrates that
`--edit-todo' notices dropped commits, but not when the command is
incorrect. Then, we restore the original todo list, and edit it to
remove the last line. This demonstrates that if we add a commit after
the initial edit, then remove it, `--edit-todo' will notice that it
has been dropped. Then, the actual rebase takes place. In the third
test, it is also checked that `--continue' will refuse to resume the
rebase if commits were dropped. The fourth test checks that no errors
are raised when resuming a rebase after resolving a conflict, the fifth
checks that no errors are raised when editing the todo list after
pausing the rebase.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-29 05:12:46 +08:00
|
|
|
|
|
|
|
|
if (file_exists(rebase_path_dropped())) {
|
|
|
|
|
if ((res = todo_list_check_against_backup(r, &todo_list)))
|
|
|
|
|
goto release_todo_list;
|
|
|
|
|
|
|
|
|
|
unlink(rebase_path_dropped());
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-29 07:02:03 +08:00
|
|
|
if (commit_staged_changes(r, opts, &todo_list)) {
|
|
|
|
|
res = -1;
|
|
|
|
|
goto release_todo_list;
|
|
|
|
|
}
|
2017-01-02 23:27:30 +08:00
|
|
|
} else if (!file_exists(get_todo_path(opts)))
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
return continue_single_pick(r, opts);
|
2018-11-10 13:48:57 +08:00
|
|
|
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 */
|
2020-08-22 00:59:35 +08:00
|
|
|
if (refs_ref_exists(get_main_ref_store(r),
|
|
|
|
|
"CHERRY_PICK_HEAD") ||
|
2020-08-22 00:59:37 +08:00
|
|
|
refs_ref_exists(get_main_ref_store(r), "REVERT_HEAD")) {
|
sequencer: fix edit handling for cherry-pick and revert messages
save_opts() should save any non-default values. It was intended to do
this, but since most options in struct replay_opts default to 0, it only
saved non-zero values. Unfortunately, this does not always work for
options.edit. Roughly speaking, options.edit had a default value of 0
for cherry-pick but a default value of 1 for revert. Make save_opts()
record a value whenever it differs from the default.
options.edit was also overly simplistic; we had more than two cases.
The behavior that previously existed was as follows:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit (ignore isatty(0))
cherry-pick No edit See above
Specify --edit Edit (ignore isatty(0)) See above
Specify --no-edit (*) See above
(*) Before stopping for conflicts, No edit is the behavior. After
stopping for conflicts, the --no-edit flag is not saved so see
the first two rows.
However, the expected behavior is:
Non-conflict commits Right after Conflict
revert Edit iff isatty(0) Edit iff isatty(0)
cherry-pick No edit Edit iff isatty(0)
Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0))
Specify --no-edit No edit No edit
In order to get the expected behavior, we need to change options.edit
to a tri-state: unspecified, false, or true. When specified, we follow
what it says. When unspecified, we need to check whether the current
commit being created is resolving a conflict as well as consulting
options.action and isatty(0). While at it, add a should_edit() utility
function that compresses options.edit down to a boolean based on the
additional information for the non-conflict case.
continue_single_pick() is the function responsible for resuming after
conflict cases, regardless of whether there is one commit being picked
or many. Make this function stop assuming edit behavior in all cases,
so that it can correctly handle !isatty(0) and specific requests to not
edit the commit message.
Reported-by: Renato Botelho <garga@freebsd.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-31 14:52:20 +08:00
|
|
|
res = continue_single_pick(r, opts);
|
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;
|
|
|
|
|
|
2020-04-07 22:27:52 +08:00
|
|
|
if (read_oneliner(&buf, rebase_path_stopped_sha(),
|
|
|
|
|
READ_ONELINER_SKIP_IF_EMPTY) &&
|
2020-09-25 13:49:12 +08:00
|
|
|
!get_oid_hex(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
|
|
|
{
|
2019-08-19 17:18:22 +08:00
|
|
|
int check_todo;
|
2021-01-30 02:20:45 +08:00
|
|
|
struct todo_item item;
|
|
|
|
|
|
|
|
|
|
item.command = opts->action == REPLAY_PICK ?
|
|
|
|
|
TODO_PICK : TODO_REVERT;
|
|
|
|
|
item.commit = cmit;
|
2019-08-19 17:18:22 +08:00
|
|
|
|
2012-01-12 02:15:57 +08:00
|
|
|
setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
|
2021-01-30 02:20:45 +08:00
|
|
|
return do_pick_commit(r, &item, opts, 0, &check_todo);
|
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];
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-07 07:30:37 +08:00
|
|
|
static int labels_cmp(const void *fndata, const struct hashmap_entry *eptr,
|
|
|
|
|
const struct hashmap_entry *entry_or_key, const void *key)
|
2018-04-25 20:29:03 +08:00
|
|
|
{
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct labels_entry *a, *b;
|
|
|
|
|
|
|
|
|
|
a = container_of(eptr, const struct labels_entry, entry);
|
|
|
|
|
b = container_of(entry_or_key, const struct labels_entry, entry);
|
|
|
|
|
|
2018-04-25 20:29:03 +08:00
|
|
|
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;
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2019-11-18 07:16:09 +08:00
|
|
|
strbuf_reset(&state->buf);
|
2018-04-25 20:29:03 +08:00
|
|
|
if (!label) {
|
|
|
|
|
char *p;
|
|
|
|
|
|
2019-08-19 04:04:16 +08:00
|
|
|
strbuf_grow(&state->buf, GIT_MAX_HEXSZ);
|
2018-04-25 20:29:03 +08:00
|
|
|
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);
|
2019-08-19 04:04:16 +08:00
|
|
|
for (; i < the_hash_algo->hexsz; i++) {
|
2018-04-25 20:29:03 +08:00
|
|
|
char save = p[i];
|
|
|
|
|
p[i] = '\0';
|
|
|
|
|
if (!hashmap_get_from_hash(&state->labels,
|
|
|
|
|
strihash(p), p))
|
|
|
|
|
break;
|
|
|
|
|
p[i] = save;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-11-18 07:16:09 +08:00
|
|
|
} else {
|
2018-04-25 20:29:03 +08:00
|
|
|
struct strbuf *buf = &state->buf;
|
|
|
|
|
|
|
|
|
|
/*
|
2019-11-18 07:16:10 +08:00
|
|
|
* Sanitize labels by replacing non-alpha-numeric characters
|
|
|
|
|
* (including white-space ones) by dashes, as they might be
|
|
|
|
|
* illegal in file names (and hence in ref names).
|
|
|
|
|
*
|
|
|
|
|
* Note that we retain non-ASCII UTF-8 characters (identified
|
|
|
|
|
* via the most significant bit). They should be all acceptable
|
|
|
|
|
* in file names. We do not validate the UTF-8 here, that's not
|
|
|
|
|
* the job of this function.
|
2018-04-25 20:29:03 +08:00
|
|
|
*/
|
2019-11-18 07:16:09 +08:00
|
|
|
for (; *label; label++)
|
2019-11-18 07:16:10 +08:00
|
|
|
if ((*label & 0x80) || isalnum(*label))
|
|
|
|
|
strbuf_addch(buf, *label);
|
|
|
|
|
/* avoid leading dash and double-dashes */
|
|
|
|
|
else if (buf->len && buf->buf[buf->len - 1] != '-')
|
|
|
|
|
strbuf_addch(buf, '-');
|
|
|
|
|
if (!buf->len) {
|
|
|
|
|
strbuf_addstr(buf, "rev-");
|
|
|
|
|
strbuf_add_unique_abbrev(buf, oid, default_abbrev);
|
|
|
|
|
}
|
2019-11-18 07:16:09 +08:00
|
|
|
label = buf->buf;
|
2018-04-25 20:29:03 +08:00
|
|
|
|
2019-11-18 07:16:09 +08:00
|
|
|
if ((buf->len == the_hash_algo->hexsz &&
|
|
|
|
|
!get_oid_hex(label, &dummy)) ||
|
|
|
|
|
(buf->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.
|
|
|
|
|
*/
|
|
|
|
|
size_t len = buf->len;
|
2018-04-25 20:29:03 +08:00
|
|
|
|
2019-11-18 07:16:09 +08:00
|
|
|
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;
|
|
|
|
|
}
|
2018-04-25 20:29:03 +08:00
|
|
|
|
2019-11-18 07:16:09 +08:00
|
|
|
label = buf->buf;
|
|
|
|
|
}
|
2018-04-25 20:29:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
FLEX_ALLOC_STR(labels_entry, label, label);
|
2019-10-07 07:30:27 +08:00
|
|
|
hashmap_entry_init(&labels_entry->entry, strihash(label));
|
2019-10-07 07:30:29 +08:00
|
|
|
hashmap_add(&state->labels, &labels_entry->entry);
|
2018-04-25 20:29:03 +08:00
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
{
|
rebase: reinstate --no-keep-empty
Commit d48e5e21da ("rebase (interactive-backend): make --keep-empty the
default", 2020-02-15) turned --keep-empty (for keeping commits which
start empty) into the default. The logic underpinning that commit was:
1) 'git commit' errors out on the creation of empty commits without an
override flag
2) Once someone determines that the override is worthwhile, it's
annoying and/or harmful to required them to take extra steps in
order to keep such commits around (and to repeat such steps with
every rebase).
While the logic on which the decision was made is sound, the result was
a bit of an overcorrection. Instead of jumping to having --keep-empty
being the default, it jumped to making --keep-empty the only available
behavior. There was a simple workaround, though, which was thought to
be good enough at the time. People could still drop commits which
started empty the same way the could drop any commits: by firing up an
interactive rebase and picking out the commits they didn't want from the
list. However, there are cases where external tools might create enough
empty commits that picking all of them out is painful. As such, having
a flag to automatically remove start-empty commits may be beneficial.
Provide users a way to drop commits which start empty using a flag that
existed for years: --no-keep-empty. Interpret --keep-empty as
countermanding any previous --no-keep-empty, but otherwise leaving
--keep-empty as the default.
This might lead to some slight weirdness since commands like
git rebase --empty=drop --keep-empty
git rebase --empty=keep --no-keep-empty
look really weird despite making perfect sense (the first will drop
commits which become empty, but keep commits that started empty; the
second will keep commits which become empty, but drop commits which
started empty). However, --no-keep-empty was named years ago and we are
predominantly keeping it for backward compatibility; also we suspect it
will only be used rarely since folks already have a simple way to drop
commits they don't want with an interactive rebase.
Reported-by: Bryan Turner <bturner@atlassian.com>
Reported-by: Sami Boukortt <sami@boukortt.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-11 10:44:25 +08:00
|
|
|
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;
|
2019-07-31 23:18:49 +08:00
|
|
|
int root_with_onto = flags & TODO_LIST_ROOT_WITH_ONTO;
|
2021-08-31 05:46:02 +08:00
|
|
|
int skipped_commit = 0;
|
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);
|
2019-10-07 07:30:37 +08:00
|
|
|
hashmap_init(&state.labels, labels_cmp, NULL, 0);
|
2018-04-25 20:29:03 +08:00
|
|
|
strbuf_init(&state.buf, 32);
|
|
|
|
|
|
|
|
|
|
if (revs->cmdline.nr && (revs->cmdline.rev[0].flags & BOTTOM)) {
|
2019-11-18 19:57:47 +08:00
|
|
|
struct labels_entry *onto_label_entry;
|
2018-04-25 20:29:03 +08:00
|
|
|
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);
|
2019-11-18 19:57:47 +08:00
|
|
|
|
|
|
|
|
FLEX_ALLOC_STR(onto_label_entry, label, "onto");
|
|
|
|
|
hashmap_entry_init(&onto_label_entry->entry, strihash("onto"));
|
|
|
|
|
hashmap_add(&state.labels, &onto_label_entry->entry);
|
2018-04-25 20:29:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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);
|
2021-08-31 05:46:02 +08:00
|
|
|
if (!is_empty && (commit->object.flags & PATCHSAME)) {
|
|
|
|
|
if (flags & TODO_LIST_WARN_SKIPPED_CHERRY_PICKS)
|
|
|
|
|
warning(_("skipped previously applied commit %s"),
|
|
|
|
|
short_commit_name(commit));
|
|
|
|
|
skipped_commit = 1;
|
2018-04-25 20:29:03 +08:00
|
|
|
continue;
|
2021-08-31 05:46:02 +08:00
|
|
|
}
|
rebase: reinstate --no-keep-empty
Commit d48e5e21da ("rebase (interactive-backend): make --keep-empty the
default", 2020-02-15) turned --keep-empty (for keeping commits which
start empty) into the default. The logic underpinning that commit was:
1) 'git commit' errors out on the creation of empty commits without an
override flag
2) Once someone determines that the override is worthwhile, it's
annoying and/or harmful to required them to take extra steps in
order to keep such commits around (and to repeat such steps with
every rebase).
While the logic on which the decision was made is sound, the result was
a bit of an overcorrection. Instead of jumping to having --keep-empty
being the default, it jumped to making --keep-empty the only available
behavior. There was a simple workaround, though, which was thought to
be good enough at the time. People could still drop commits which
started empty the same way the could drop any commits: by firing up an
interactive rebase and picking out the commits they didn't want from the
list. However, there are cases where external tools might create enough
empty commits that picking all of them out is painful. As such, having
a flag to automatically remove start-empty commits may be beneficial.
Provide users a way to drop commits which start empty using a flag that
existed for years: --no-keep-empty. Interpret --keep-empty as
countermanding any previous --no-keep-empty, but otherwise leaving
--keep-empty as the default.
This might lead to some slight weirdness since commands like
git rebase --empty=drop --keep-empty
git rebase --empty=keep --no-keep-empty
look really weird despite making perfect sense (the first will drop
commits which become empty, but keep commits that started empty; the
second will keep commits which become empty, but drop commits which
started empty). However, --no-keep-empty was named years ago and we are
predominantly keeping it for backward compatibility; also we suspect it
will only be used rarely since folks already have a simple way to drop
commits they don't want with an interactive rebase.
Reported-by: Bryan Turner <bturner@atlassian.com>
Reported-by: Sami Boukortt <sami@boukortt.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-11 10:44:25 +08:00
|
|
|
if (is_empty && !keep_empty)
|
|
|
|
|
continue;
|
2018-04-25 20:29:03 +08:00
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
strbuf_addf(&buf, "%s %s %s", cmd_pick,
|
|
|
|
|
oid_to_hex(&commit->object.oid),
|
|
|
|
|
oneline.buf);
|
2020-04-11 10:44:24 +08:00
|
|
|
if (is_empty)
|
|
|
|
|
strbuf_addf(&buf, " %c empty",
|
|
|
|
|
comment_line_char);
|
2018-04-25 20:29:03 +08:00
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
2021-08-31 05:46:02 +08:00
|
|
|
if (skipped_commit)
|
|
|
|
|
advise_if_enabled(ADVICE_SKIPPED_CHERRY_PICKS,
|
|
|
|
|
_("use --reapply-cherry-picks to include skipped commits"));
|
2018-04-25 20:29:03 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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);
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-06 01:07:23 +08:00
|
|
|
/* Add HEAD as implicit "tip of branch" */
|
2018-04-25 20:29:03 +08:00
|
|
|
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,
|
2019-07-31 23:18:49 +08:00
|
|
|
rebase_cousins || root_with_onto ?
|
|
|
|
|
"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);
|
2020-11-03 02:55:05 +08:00
|
|
|
hashmap_clear_and_free(&state.labels, struct labels_entry, entry);
|
2018-04-25 20:29:03 +08:00
|
|
|
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;
|
rebase: reinstate --no-keep-empty
Commit d48e5e21da ("rebase (interactive-backend): make --keep-empty the
default", 2020-02-15) turned --keep-empty (for keeping commits which
start empty) into the default. The logic underpinning that commit was:
1) 'git commit' errors out on the creation of empty commits without an
override flag
2) Once someone determines that the override is worthwhile, it's
annoying and/or harmful to required them to take extra steps in
order to keep such commits around (and to repeat such steps with
every rebase).
While the logic on which the decision was made is sound, the result was
a bit of an overcorrection. Instead of jumping to having --keep-empty
being the default, it jumped to making --keep-empty the only available
behavior. There was a simple workaround, though, which was thought to
be good enough at the time. People could still drop commits which
started empty the same way the could drop any commits: by firing up an
interactive rebase and picking out the commits they didn't want from the
list. However, there are cases where external tools might create enough
empty commits that picking all of them out is painful. As such, having
a flag to automatically remove start-empty commits may be beneficial.
Provide users a way to drop commits which start empty using a flag that
existed for years: --no-keep-empty. Interpret --keep-empty as
countermanding any previous --no-keep-empty, but otherwise leaving
--keep-empty as the default.
This might lead to some slight weirdness since commands like
git rebase --empty=drop --keep-empty
git rebase --empty=keep --no-keep-empty
look really weird despite making perfect sense (the first will drop
commits which become empty, but keep commits that started empty; the
second will keep commits which become empty, but drop commits which
started empty). However, --no-keep-empty was named years ago and we are
predominantly keeping it for backward compatibility; also we suspect it
will only be used rarely since folks already have a simple way to drop
commits they don't want with an interactive rebase.
Reported-by: Bryan Turner <bturner@atlassian.com>
Reported-by: Sami Boukortt <sami@boukortt.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-11 10:44:25 +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;
|
2020-04-11 10:44:27 +08:00
|
|
|
int reapply_cherry_picks = flags & TODO_LIST_REAPPLY_CHERRY_PICKS;
|
2021-08-31 05:46:02 +08:00
|
|
|
int skipped_commit = 0;
|
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;
|
2020-04-11 10:44:27 +08:00
|
|
|
revs.cherry_mark = !reapply_cherry_picks;
|
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))) {
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
int is_empty = is_original_commit_empty(commit);
|
2018-03-20 18:03:14 +08:00
|
|
|
|
2021-08-31 05:46:02 +08:00
|
|
|
if (!is_empty && (commit->object.flags & PATCHSAME)) {
|
|
|
|
|
if (flags & TODO_LIST_WARN_SKIPPED_CHERRY_PICKS)
|
|
|
|
|
warning(_("skipped previously applied commit %s"),
|
|
|
|
|
short_commit_name(commit));
|
|
|
|
|
skipped_commit = 1;
|
2018-03-20 18:03:14 +08:00
|
|
|
continue;
|
2021-08-31 05:46:02 +08:00
|
|
|
}
|
rebase: reinstate --no-keep-empty
Commit d48e5e21da ("rebase (interactive-backend): make --keep-empty the
default", 2020-02-15) turned --keep-empty (for keeping commits which
start empty) into the default. The logic underpinning that commit was:
1) 'git commit' errors out on the creation of empty commits without an
override flag
2) Once someone determines that the override is worthwhile, it's
annoying and/or harmful to required them to take extra steps in
order to keep such commits around (and to repeat such steps with
every rebase).
While the logic on which the decision was made is sound, the result was
a bit of an overcorrection. Instead of jumping to having --keep-empty
being the default, it jumped to making --keep-empty the only available
behavior. There was a simple workaround, though, which was thought to
be good enough at the time. People could still drop commits which
started empty the same way the could drop any commits: by firing up an
interactive rebase and picking out the commits they didn't want from the
list. However, there are cases where external tools might create enough
empty commits that picking all of them out is painful. As such, having
a flag to automatically remove start-empty commits may be beneficial.
Provide users a way to drop commits which start empty using a flag that
existed for years: --no-keep-empty. Interpret --keep-empty as
countermanding any previous --no-keep-empty, but otherwise leaving
--keep-empty as the default.
This might lead to some slight weirdness since commands like
git rebase --empty=drop --keep-empty
git rebase --empty=keep --no-keep-empty
look really weird despite making perfect sense (the first will drop
commits which become empty, but keep commits that started empty; the
second will keep commits which become empty, but drop commits which
started empty). However, --no-keep-empty was named years ago and we are
predominantly keeping it for backward compatibility; also we suspect it
will only be used rarely since folks already have a simple way to drop
commits they don't want with an interactive rebase.
Reported-by: Bryan Turner <bturner@atlassian.com>
Reported-by: Sami Boukortt <sami@boukortt.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-11 10:44:25 +08:00
|
|
|
if (is_empty && !keep_empty)
|
|
|
|
|
continue;
|
2019-03-06 03:17:56 +08:00
|
|
|
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);
|
2020-04-11 10:44:24 +08:00
|
|
|
if (is_empty)
|
|
|
|
|
strbuf_addf(out, " %c empty", comment_line_char);
|
2019-03-06 03:17:56 +08:00
|
|
|
strbuf_addch(out, '\n');
|
2017-07-14 22:44:58 +08:00
|
|
|
}
|
2021-08-31 05:46:02 +08:00
|
|
|
if (skipped_commit)
|
|
|
|
|
advise_if_enabled(ADVICE_SKIPPED_CHERRY_PICKS,
|
|
|
|
|
_("use --reapply-cherry-picks to include skipped commits"));
|
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.
|
|
|
|
|
*/
|
2021-09-08 05:05:12 +08:00
|
|
|
static 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
|
|
|
|
2021-03-14 00:17:22 +08:00
|
|
|
CALLOC_ARRAY(base_items, commands->nr);
|
2019-03-06 03:17:54 +08:00
|
|
|
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
|
|
|
*
|
2019-11-06 01:07:23 +08:00
|
|
|
* As we insert the exec commands immediately after rearranging
|
2019-03-06 03:17:54 +08:00
|
|
|
* 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> */
|
sequencer: avoid adding exec commands for non-commit creating commands
The `--exec <cmd>` is documented as
Append "exec <cmd>" after each line creating a commit in the final
history.
...
If --autosquash is used, "exec" lines will not be appended for the
intermediate commits, and will only appear at the end of each
squash/fixup series.
Unfortunately, it would also add exec commands after non-pick
operations, such as 'no-op', which could be seen for example with
git rebase -i --exec true HEAD
todo_list_add_exec_commands() intent was to insert exec commands after
each logical pick, while trying to consider a chains of fixup and squash
commits to be part of the pick before it. So it would keep an 'insert'
boolean tracking if it had seen a pick or merge, but not write the exec
command until it saw the next non-fixup/squash command. Since that
would make it miss the final exec command, it had some code that would
check whether it still needed to insert one at the end, but instead of a
simple
if (insert)
it had a
if (insert || <condition that is always true>)
That's buggy; as per the docs, we should only add exec commands for
lines that create commits, i.e. only if insert is true. Fix the
conditional.
There was one testcase in the testsuite that we tweak for this change;
it was introduced in 54fd3243da ("rebase -i: reread the todo list if
`exec` touched it", 2017-04-26), and was merely testing that after an
exec had fired that the todo list would be re-read. The test at the
time would have worked given any revision at all, though it would only
work with 'HEAD' as a side-effect of this bug. Since we're fixing this
bug, choose something other than 'HEAD' for that test.
Finally, add a testcase that verifies when we have no commits to pick,
that we get no exec lines in the generated todo list.
Reported-by: Nikita Bobko <nikitabobko@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-30 11:58:39 +08:00
|
|
|
if (insert) {
|
2019-03-06 03:17:54 +08:00
|
|
|
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++) {
|
2020-03-30 20:42:35 +08:00
|
|
|
char cmd;
|
|
|
|
|
|
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 */
|
2020-03-30 20:42:35 +08:00
|
|
|
cmd = command_to_char(item->command);
|
|
|
|
|
if ((flags & TODO_LIST_ABBREVIATE_CMDS) && cmd)
|
|
|
|
|
strbuf_addch(buf, cmd);
|
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);
|
|
|
|
|
|
2021-01-30 02:20:47 +08:00
|
|
|
if (item->command == TODO_FIXUP) {
|
|
|
|
|
if (item->flags & TODO_EDIT_FIXUP_MSG)
|
|
|
|
|
strbuf_addstr(buf, " -c");
|
|
|
|
|
else if (item->flags & TODO_REPLACE_FIXUP_MSG) {
|
|
|
|
|
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
|
|
|
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)
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
append_todo_help(count_commands(todo_list),
|
2019-03-06 03:18:02 +08:00
|
|
|
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
|
|
|
|
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;
|
2019-11-25 01:43:29 +08:00
|
|
|
todo_list->done_nr += i;
|
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,
|
2020-11-04 23:29:38 +08:00
|
|
|
struct commit *onto, const struct object_id *orig_head,
|
2019-04-17 22:30:39 +08:00
|
|
|
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
|
|
|
{
|
2020-08-14 01:42:57 +08:00
|
|
|
char shortonto[GIT_MAX_HEXSZ + 1];
|
|
|
|
|
const char *todo_file = rebase_path_todo();
|
2019-03-06 03:17:57 +08:00
|
|
|
struct todo_list new_todo = TODO_LIST_INIT;
|
rebase -i: re-fix short SHA-1 collision
In 66ae9a57b88 (t3404: rebase -i: demonstrate short SHA-1 collision,
2013-08-23), we added a test case that demonstrated how it is possible
that a previously unambiguous short commit ID could become ambiguous
*during* a rebase.
In 75c69766554 (rebase -i: fix short SHA-1 collision, 2013-08-23), we
fixed that problem simply by writing out the todo list with expanded
commit IDs (except *right* before letting the user edit the todo list,
in which case we shorten them, but we expand them right after the file
was edited).
However, the bug resurfaced as a side effect of 393adf7a6f6 (sequencer:
directly call pick_commits() from complete_action(), 2019-11-24): as of
this commit, the sequencer no longer re-reads the todo list after
writing it out with expanded commit IDs.
The only redeeming factor is that the todo list is already parsed at
that stage, including all the commits corresponding to the commands,
therefore the sequencer can continue even if the internal todo list has
short commit IDs.
That does not prevent problems, though: the sequencer writes out the
`done` and `git-rebase-todo` files incrementally (i.e. overwriting the
todo list with a version that has _short_ commit IDs), and if a merge
conflict happens, or if an `edit` or a `break` command is encountered, a
subsequent `git rebase --continue` _will_ re-read the todo list, opening
an opportunity for the "short SHA-1 collision" bug again.
To avoid that, let's make sure that we do expand the commit IDs in the
todo list as soon as we have parsed it after letting the user edit it.
Additionally, we improve the 'short SHA-1 collide' test case in t3404 to
test specifically for the case where the rebase is resumed. We also
hard-code the expected colliding short SHA-1s, to document the
expectation (and to make it easier on future readers).
Note that we specifically test that the short commit ID is used in the
`git-rebase-todo.tmp` file: this file is created by the fake editor in
the test script and reflects the state that would have been presented to
the user to edit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-23 20:28:18 +08:00
|
|
|
struct strbuf *buf = &todo_list->buf, buf2 = STRBUF_INIT;
|
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
|
|
|
|
2020-08-14 01:42:57 +08:00
|
|
|
find_unique_abbrev_r(shortonto, &oid, DEFAULT_ABBREV);
|
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 (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) {
|
2020-04-07 22:27:56 +08:00
|
|
|
apply_autostash(rebase_path_autostash());
|
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
|
|
|
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) {
|
2020-04-07 22:27:56 +08:00
|
|
|
apply_autostash(rebase_path_autostash());
|
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
|
|
|
sequencer_remove_state(opts);
|
|
|
|
|
|
|
|
|
|
return -1;
|
2019-03-06 03:18:04 +08:00
|
|
|
} else if (res == -3) {
|
2020-04-07 22:27:56 +08:00
|
|
|
apply_autostash(rebase_path_autostash());
|
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
|
|
|
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"));
|
rebase-interactive: warn if commit is dropped with `rebase --edit-todo'
When set to "warn" or "error", `rebase.missingCommitsCheck' would make
`rebase -i' warn if the user removed commits from the todo list to
prevent mistakes. Unfortunately, `rebase --edit-todo' and `rebase
--continue' don't take it into account.
This adds the ability for `rebase --edit-todo' and `rebase --continue'
to check if commits were dropped by the user. As both edit_todo_list()
and complete_action() parse the todo list and check for dropped commits,
the code doing so in the latter is removed to reduce duplication.
`edit_todo_list_advice' is removed from sequencer.c as it is no longer
used there.
This changes when a backup of the todo list is made. Until now, it was
saved only once, before the initial edit. Now, it is also made if the
original todo list has no errors or no dropped commits. Thus, the
backup should be error-free. Without this, sequencer_continue()
(`rebase --continue') could only compare the current todo list against
the original, unedited list. Before this change, this file was only
used by edit_todo_list() and `rebase -p' to create the backup before
the initial edit, and check_todo_list_from_file(), only used by
`rebase -p' to check for dropped commits after its own initial edit.
If the edited list has an error, a file, `dropped', is created to
report the issue. Otherwise, it is deleted. Usually, the edited list
is compared against the list before editing, but if this file exists,
it will be compared to the backup. Also, if the file exists,
sequencer_continue() checks the list for dropped commits. If the
check was performed every time, it would fail when resuming a rebase
after resolving a conflict, as the backup will contain commits that
were picked, but they will not be in the new list. It's safe to
ignore this check if `dropped' does not exist, because that means that
no errors were found at the last edition, so any missing commits here
have already been picked.
Five tests are added to t3404. The tests for
`rebase.missingCommitsCheck = warn' and `rebase.missingCommitsCheck =
error' have a similar structure. First, we start a rebase with an
incorrect command on the first line. Then, we edit the todo list,
removing the first and the last lines. This demonstrates that
`--edit-todo' notices dropped commits, but not when the command is
incorrect. Then, we restore the original todo list, and edit it to
remove the last line. This demonstrates that if we add a commit after
the initial edit, then remove it, `--edit-todo' will notice that it
has been dropped. Then, the actual rebase takes place. In the third
test, it is also checked that `--continue' will refuse to resume the
rebase if commits were dropped. The fourth test checks that no errors
are raised when resuming a rebase after resolving a conflict, the fifth
checks that no errors are raised when editing the todo list after
pausing the rebase.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-29 05:12:46 +08:00
|
|
|
} else if (res == -4) {
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
rebase -i: re-fix short SHA-1 collision
In 66ae9a57b88 (t3404: rebase -i: demonstrate short SHA-1 collision,
2013-08-23), we added a test case that demonstrated how it is possible
that a previously unambiguous short commit ID could become ambiguous
*during* a rebase.
In 75c69766554 (rebase -i: fix short SHA-1 collision, 2013-08-23), we
fixed that problem simply by writing out the todo list with expanded
commit IDs (except *right* before letting the user edit the todo list,
in which case we shorten them, but we expand them right after the file
was edited).
However, the bug resurfaced as a side effect of 393adf7a6f6 (sequencer:
directly call pick_commits() from complete_action(), 2019-11-24): as of
this commit, the sequencer no longer re-reads the todo list after
writing it out with expanded commit IDs.
The only redeeming factor is that the todo list is already parsed at
that stage, including all the commits corresponding to the commands,
therefore the sequencer can continue even if the internal todo list has
short commit IDs.
That does not prevent problems, though: the sequencer writes out the
`done` and `git-rebase-todo` files incrementally (i.e. overwriting the
todo list with a version that has _short_ commit IDs), and if a merge
conflict happens, or if an `edit` or a `break` command is encountered, a
subsequent `git rebase --continue` _will_ re-read the todo list, opening
an opportunity for the "short SHA-1 collision" bug again.
To avoid that, let's make sure that we do expand the commit IDs in the
todo list as soon as we have parsed it after letting the user edit it.
Additionally, we improve the 'short SHA-1 collide' test case in t3404 to
test specifically for the case where the rebase is resumed. We also
hard-code the expected colliding short SHA-1s, to document the
expectation (and to make it easier on future readers).
Note that we specifically test that the short commit ID is used in the
`git-rebase-todo.tmp` file: this file is created by the fake editor in
the test script and reflects the state that would have been presented to
the user to edit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-23 20:28:18 +08:00
|
|
|
/* Expand the commit IDs */
|
|
|
|
|
todo_list_to_strbuf(r, &new_todo, &buf2, -1, 0);
|
|
|
|
|
strbuf_swap(&new_todo.buf, &buf2);
|
|
|
|
|
strbuf_release(&buf2);
|
|
|
|
|
new_todo.total_nr -= new_todo.nr;
|
|
|
|
|
if (todo_list_parse_insn_buffer(r, new_todo.buf.buf, &new_todo) < 0)
|
|
|
|
|
BUG("invalid todo list after expanding IDs:\n%s",
|
|
|
|
|
new_todo.buf.buf);
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-25 01:43:32 +08:00
|
|
|
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
|
|
|
|
2019-04-17 22:30:39 +08:00
|
|
|
if (checkout_onto(r, opts, onto_name, &oid, orig_head))
|
2019-11-25 01:43:32 +08:00
|
|
|
goto cleanup;
|
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))
|
2019-11-25 01:43:32 +08:00
|
|
|
goto cleanup;
|
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-11-25 01:43:32 +08:00
|
|
|
todo_list_write_total_nr(&new_todo);
|
|
|
|
|
res = pick_commits(r, &new_todo, opts);
|
|
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
|
todo_list_release(&new_todo);
|
|
|
|
|
|
|
|
|
|
return 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
|
|
|
}
|
|
|
|
|
|
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,
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct hashmap_entry *eptr,
|
|
|
|
|
const struct hashmap_entry *entry_or_key,
|
|
|
|
|
const void *key)
|
2017-07-14 22:45:31 +08:00
|
|
|
{
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct subject2item_entry *a, *b;
|
|
|
|
|
|
|
|
|
|
a = container_of(eptr, const struct subject2item_entry, entry);
|
|
|
|
|
b = container_of(entry_or_key, const struct subject2item_entry, entry);
|
|
|
|
|
|
2017-07-14 22:45:31 +08:00
|
|
|
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 *);
|
|
|
|
|
|
2021-02-09 03:25:20 +08:00
|
|
|
static int skip_fixupish(const char *subject, const char **p) {
|
2021-01-30 02:20:49 +08:00
|
|
|
return skip_prefix(subject, "fixup! ", p) ||
|
|
|
|
|
skip_prefix(subject, "amend! ", p) ||
|
|
|
|
|
skip_prefix(subject, "squash! ", p);
|
|
|
|
|
}
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2019-10-07 07:30:37 +08:00
|
|
|
hashmap_init(&subject2item, subject2item_cmp, NULL, todo_list->nr);
|
2019-03-06 03:17:55 +08:00
|
|
|
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);
|
2019-11-08 17:43:46 +08:00
|
|
|
commit_buffer = logmsg_reencode(item->commit, NULL, "UTF-8");
|
2017-07-14 22:45:31 +08:00
|
|
|
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);
|
2021-02-09 03:25:20 +08:00
|
|
|
if (skip_fixupish(subject, &p)) {
|
2017-07-14 22:45:31 +08:00
|
|
|
struct commit *commit2;
|
|
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
while (isspace(*p))
|
|
|
|
|
p++;
|
2021-02-09 03:25:20 +08:00
|
|
|
if (!skip_fixupish(p, &p))
|
2017-07-14 22:45:31 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-07 07:30:36 +08:00
|
|
|
entry = hashmap_get_entry_from_hash(&subject2item,
|
|
|
|
|
strhash(p), p,
|
|
|
|
|
struct subject2item_entry,
|
|
|
|
|
entry);
|
|
|
|
|
if (entry)
|
2017-07-14 22:45:31 +08:00
|
|
|
/* 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;
|
2021-01-30 02:20:49 +08:00
|
|
|
if (starts_with(subject, "fixup!")) {
|
|
|
|
|
todo_list->items[i].command = TODO_FIXUP;
|
|
|
|
|
} else if (starts_with(subject, "amend!")) {
|
|
|
|
|
todo_list->items[i].command = TODO_FIXUP;
|
|
|
|
|
todo_list->items[i].flags = TODO_REPLACE_FIXUP_MSG;
|
|
|
|
|
} else {
|
|
|
|
|
todo_list->items[i].command = TODO_SQUASH;
|
|
|
|
|
}
|
rebase --autosquash: fix a potential segfault
When rearranging the todo list so that the fixups/squashes are reordered
just after the commits they intend to fix up, we use two arrays to
maintain that list: `next` and `tail`.
The idea is that `next[i]`, if set to a non-negative value, contains the
index of the item that should be rearranged just after the `i`th item.
To avoid having to walk the entire `next` chain when appending another
fixup/squash, we also store the end of the `next` chain in `tail[i]`.
The logic we currently use to update these array items is based on the
assumption that given a fixup/squash item at index `i`, we just found
the index `i2` indicating the first item in that fixup chain.
However, as reported by Paul Ganssle, that need not be true: the special
form `fixup! <commit-hash>` is allowed to point to _another_ fixup
commit in the middle of the fixup chain.
Example:
* 0192a To fixup
* 02f12 fixup! To fixup
* 03763 fixup! To fixup
* 04ecb fixup! 02f12
Note how the fourth commit targets the second commit, which is already a
fixup that targets the first commit.
Previously, we would update `next` and `tail` under our assumption that
every `fixup!` commit would find the start of the `fixup!`/`squash!`
chain. This would lead to a segmentation fault because we would actually
end up with a `next[i]` pointing to a `fixup!` but the corresponding
`tail[i]` pointing nowhere, which would the lead to a segmentation
fault.
Let's fix this by _inserting_, rather than _appending_, the item. In
other words, if we make a given line successor of another line, we do
not simply forget any previously set successor of the latter, but make
it a successor of the former.
In the above example, at the point when we insert 04ecb just after
02f12, 03763 would already be recorded as a successor of 04ecb, and we
now "squeeze in" 04ecb.
To complete the idea, we now no longer assume that `next[i]` pointing to
a line means that `last[i]` points to a line, too. Instead, we extend
the concept of `last` to cover also partial `fixup!`/`squash!` chains,
i.e. chains starting in the middle of a larger such chain.
In the above example, after processing all lines, `last[0]`
(corresponding to 0192a) would point to 03763, which indeed is the end
of the overall `fixup!` chain, and `last[1]` (corresponding to 02f12)
would point to 04ecb (which is the last `fixup!` targeting 02f12, but it
has 03763 as successor, i.e. it is not the end of overall `fixup!`
chain).
Reported-by: Paul Ganssle <paul@ganssle.io>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-10 03:23:39 +08:00
|
|
|
if (tail[i2] < 0) {
|
|
|
|
|
next[i] = next[i2];
|
2017-07-14 22:45:31 +08:00
|
|
|
next[i2] = i;
|
rebase --autosquash: fix a potential segfault
When rearranging the todo list so that the fixups/squashes are reordered
just after the commits they intend to fix up, we use two arrays to
maintain that list: `next` and `tail`.
The idea is that `next[i]`, if set to a non-negative value, contains the
index of the item that should be rearranged just after the `i`th item.
To avoid having to walk the entire `next` chain when appending another
fixup/squash, we also store the end of the `next` chain in `tail[i]`.
The logic we currently use to update these array items is based on the
assumption that given a fixup/squash item at index `i`, we just found
the index `i2` indicating the first item in that fixup chain.
However, as reported by Paul Ganssle, that need not be true: the special
form `fixup! <commit-hash>` is allowed to point to _another_ fixup
commit in the middle of the fixup chain.
Example:
* 0192a To fixup
* 02f12 fixup! To fixup
* 03763 fixup! To fixup
* 04ecb fixup! 02f12
Note how the fourth commit targets the second commit, which is already a
fixup that targets the first commit.
Previously, we would update `next` and `tail` under our assumption that
every `fixup!` commit would find the start of the `fixup!`/`squash!`
chain. This would lead to a segmentation fault because we would actually
end up with a `next[i]` pointing to a `fixup!` but the corresponding
`tail[i]` pointing nowhere, which would the lead to a segmentation
fault.
Let's fix this by _inserting_, rather than _appending_, the item. In
other words, if we make a given line successor of another line, we do
not simply forget any previously set successor of the latter, but make
it a successor of the former.
In the above example, at the point when we insert 04ecb just after
02f12, 03763 would already be recorded as a successor of 04ecb, and we
now "squeeze in" 04ecb.
To complete the idea, we now no longer assume that `next[i]` pointing to
a line means that `last[i]` points to a line, too. Instead, we extend
the concept of `last` to cover also partial `fixup!`/`squash!` chains,
i.e. chains starting in the middle of a larger such chain.
In the above example, after processing all lines, `last[0]`
(corresponding to 0192a) would point to 03763, which indeed is the end
of the overall `fixup!` chain, and `last[1]` (corresponding to 02f12)
would point to 04ecb (which is the last `fixup!` targeting 02f12, but it
has 03763 as successor, i.e. it is not the end of overall `fixup!`
chain).
Reported-by: Paul Ganssle <paul@ganssle.io>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-10 03:23:39 +08:00
|
|
|
} else {
|
|
|
|
|
next[i] = next[tail[i2]];
|
2017-07-14 22:45:31 +08:00
|
|
|
next[tail[i2]] = i;
|
rebase --autosquash: fix a potential segfault
When rearranging the todo list so that the fixups/squashes are reordered
just after the commits they intend to fix up, we use two arrays to
maintain that list: `next` and `tail`.
The idea is that `next[i]`, if set to a non-negative value, contains the
index of the item that should be rearranged just after the `i`th item.
To avoid having to walk the entire `next` chain when appending another
fixup/squash, we also store the end of the `next` chain in `tail[i]`.
The logic we currently use to update these array items is based on the
assumption that given a fixup/squash item at index `i`, we just found
the index `i2` indicating the first item in that fixup chain.
However, as reported by Paul Ganssle, that need not be true: the special
form `fixup! <commit-hash>` is allowed to point to _another_ fixup
commit in the middle of the fixup chain.
Example:
* 0192a To fixup
* 02f12 fixup! To fixup
* 03763 fixup! To fixup
* 04ecb fixup! 02f12
Note how the fourth commit targets the second commit, which is already a
fixup that targets the first commit.
Previously, we would update `next` and `tail` under our assumption that
every `fixup!` commit would find the start of the `fixup!`/`squash!`
chain. This would lead to a segmentation fault because we would actually
end up with a `next[i]` pointing to a `fixup!` but the corresponding
`tail[i]` pointing nowhere, which would the lead to a segmentation
fault.
Let's fix this by _inserting_, rather than _appending_, the item. In
other words, if we make a given line successor of another line, we do
not simply forget any previously set successor of the latter, but make
it a successor of the former.
In the above example, at the point when we insert 04ecb just after
02f12, 03763 would already be recorded as a successor of 04ecb, and we
now "squeeze in" 04ecb.
To complete the idea, we now no longer assume that `next[i]` pointing to
a line means that `last[i]` points to a line, too. Instead, we extend
the concept of `last` to cover also partial `fixup!`/`squash!` chains,
i.e. chains starting in the middle of a larger such chain.
In the above example, after processing all lines, `last[0]`
(corresponding to 0192a) would point to 03763, which indeed is the end
of the overall `fixup!` chain, and `last[1]` (corresponding to 02f12)
would point to 04ecb (which is the last `fixup!` targeting 02f12, but it
has 03763 as successor, i.e. it is not the end of overall `fixup!`
chain).
Reported-by: Paul Ganssle <paul@ganssle.io>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-10 03:23:39 +08:00
|
|
|
}
|
2017-07-14 22:45:31 +08:00
|
|
|
tail[i2] = i;
|
|
|
|
|
} else if (!hashmap_get_from_hash(&subject2item,
|
|
|
|
|
strhash(subject), subject)) {
|
|
|
|
|
FLEX_ALLOC_MEM(entry, subject, subject, subject_len);
|
|
|
|
|
entry->i = i;
|
2019-10-07 07:30:27 +08:00
|
|
|
hashmap_entry_init(&entry->entry,
|
|
|
|
|
strhash(entry->subject));
|
2019-10-07 07:30:32 +08:00
|
|
|
hashmap_put(&subject2item, &entry->entry);
|
2017-07-14 22:45:31 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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);
|
2020-11-03 02:55:05 +08:00
|
|
|
hashmap_clear_and_free(&subject2item, struct subject2item_entry, entry);
|
2017-07-14 22:45:31 +08:00
|
|
|
|
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
|
|
|
}
|
2019-12-07 00:06:11 +08:00
|
|
|
|
|
|
|
|
int sequencer_determine_whence(struct repository *r, enum commit_whence *whence)
|
|
|
|
|
{
|
2020-08-22 00:59:35 +08:00
|
|
|
if (refs_ref_exists(get_main_ref_store(r), "CHERRY_PICK_HEAD")) {
|
2019-12-07 00:06:12 +08:00
|
|
|
struct object_id cherry_pick_head, rebase_head;
|
|
|
|
|
|
|
|
|
|
if (file_exists(git_path_seq_dir()))
|
|
|
|
|
*whence = FROM_CHERRY_PICK_MULTI;
|
|
|
|
|
if (file_exists(rebase_path()) &&
|
|
|
|
|
!get_oid("REBASE_HEAD", &rebase_head) &&
|
|
|
|
|
!get_oid("CHERRY_PICK_HEAD", &cherry_pick_head) &&
|
|
|
|
|
oideq(&rebase_head, &cherry_pick_head))
|
|
|
|
|
*whence = FROM_REBASE_PICK;
|
|
|
|
|
else
|
|
|
|
|
*whence = FROM_CHERRY_PICK_SINGLE;
|
|
|
|
|
|
2019-12-07 00:06:11 +08:00
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
