[1/1] rebase -i: introduce the 'break' command
diff mbox series

Message ID b358178548bdc9134d4e4b83b1d0384ebb257a72.1538578818.git.gitgitgadget@gmail.com
State New
Headers show
Series
  • rebase -i: introduce the 'break' command
Related show

Commit Message

Derrick Stolee via GitGitGadget Oct. 3, 2018, 3 p.m. UTC
From: Johannes Schindelin <johannes.schindelin@gmx.de>

The 'edit' command can be used to cherry-pick a commit and then
immediately drop out of the interactive rebase, with exit code 0, to let
the user amend the commit, or test it, or look around.

Sometimes this functionality would come in handy *without*
cherry-picking a commit, e.g. to interrupt the interactive rebase even
before cherry-picking a commit, or immediately after an 'exec' or a
'merge'.

This commit introduces that functionality, as the spanking new 'break' command.

Suggested-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 rebase-interactive.c       | 1 +
 sequencer.c                | 7 ++++++-
 t/lib-rebase.sh            | 2 +-
 t/t3418-rebase-continue.sh | 9 +++++++++
 4 files changed, 17 insertions(+), 2 deletions(-)

Comments

Junio C Hamano Oct. 5, 2018, 8:15 a.m. UTC | #1
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> The 'edit' command can be used to cherry-pick a commit and then
> immediately drop out of the interactive rebase, with exit code 0, to let
> the user amend the commit, or test it, or look around.
>
> Sometimes this functionality would come in handy *without*
> cherry-picking a commit, e.g. to interrupt the interactive rebase even
> before cherry-picking a commit, or immediately after an 'exec' or a
> 'merge'.
>
> This commit introduces that functionality, as the spanking new 'break' command.
>
> Suggested-by: Stefan Beller <sbeller@google.com>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---

If one wants to emulate this with the versions of Git that are
currently deployed, would it be sufficient to insert "exec false"
instead of "break"?

The reason I am asking is *not* to imply that we do not need this
new feature.  It is because I vaguely recall seeing a request to add
'pause' to the insn set and "exec false" was mentioned as a more
general alternative long time ago.  I am trying to see if this is a
recurring request/wish, because it would reinforce that this new
feature would be a good addition if that is the case.

I suspect that "exec false" would give a message that looks like a
complaint ("'false' failed so we are giving you control back to fix
things" or something like that), and having a dedicated way to pause
the execution without alarming the user is a good idea.

I think the earlier request asked for 'pause' (I didn't dig the list
archive very carefully, though), and 'stop' may also be a possible
verb, but I tend to agree with this patch that 'break' is probably
the best choice, simply because it begins with 'b' in the
abbreviated form, a letter that is not yet used by others (unlike
'pause' or 'stop' that would want 'p' and 's' that are already
taken)..

Here is a tangent, but I think the description of "-x <cmd>" in "git
rebase --continue" should mention that a failing command would
interrupt the sequencer.  That fact about "exec" command is given
much later in the last part of the "interactive mode" section of the
manual, so technically our docs are not being incomplete, but the
current description is not helpful to those who are looking for
substring "exec" from the beginning of the documentation to find out
if the exit status of the command affects the way commits are
replayed (which is what I was doing when imagining how users would
emulate this feature with deployed versions of Git).

Perhaps something as simple as this...

 Documentation/git-rebase.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 0e20a66e73..0fc5a851b5 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -420,7 +420,8 @@ idea unless you know what you are doing (see BUGS below).
 --exec <cmd>::
 	Append "exec <cmd>" after each line creating a commit in the
 	final history. <cmd> will be interpreted as one or more shell
-	commands.
+	commands, and interrupts the rebase session when it exits with
+	non-zero status.
 +
 You may execute several commands by either using one instance of `--exec`
 with several commands:


Also, it seems that this has some interaction with the topics in
flight; the added test does pass when queued on top of 'master', but
fails when merged to 'pu'.  I didn't look into the details as I am
not fully online yet.

Thanks.
Jacob Keller Oct. 5, 2018, 8:36 a.m. UTC | #2
On Fri, Oct 5, 2018 at 1:17 AM Junio C Hamano <gitster@pobox.com> wrote:
> If one wants to emulate this with the versions of Git that are
> currently deployed, would it be sufficient to insert "exec false"
> instead of "break"?
>
> The reason I am asking is *not* to imply that we do not need this
> new feature.  It is because I vaguely recall seeing a request to add
> 'pause' to the insn set and "exec false" was mentioned as a more
> general alternative long time ago.  I am trying to see if this is a
> recurring request/wish, because it would reinforce that this new
> feature would be a good addition if that is the case.
>
> I suspect that "exec false" would give a message that looks like a
> complaint ("'false' failed so we are giving you control back to fix
> things" or something like that), and having a dedicated way to pause
> the execution without alarming the user is a good idea.
>
> I think the earlier request asked for 'pause' (I didn't dig the list
> archive very carefully, though), and 'stop' may also be a possible
> verb, but I tend to agree with this patch that 'break' is probably
> the best choice, simply because it begins with 'b' in the
> abbreviated form, a letter that is not yet used by others (unlike
> 'pause' or 'stop' that would want 'p' and 's' that are already
> taken)..
>

Yea. I use "exec false" all the time for this purpose, but it's a bit
confusing, and it does cause rebase to indicate that a command failed.

I think adding a builtin command to do this is a good idea, and I
think break is a reasonable verb, (especially considering the
shorthand "b").

Regards,
Jake
Johannes Schindelin Oct. 5, 2018, 3:36 p.m. UTC | #3
Hi Junio,

On Fri, 5 Oct 2018, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > The 'edit' command can be used to cherry-pick a commit and then
> > immediately drop out of the interactive rebase, with exit code 0, to let
> > the user amend the commit, or test it, or look around.
> >
> > Sometimes this functionality would come in handy *without*
> > cherry-picking a commit, e.g. to interrupt the interactive rebase even
> > before cherry-picking a commit, or immediately after an 'exec' or a
> > 'merge'.
> >
> > This commit introduces that functionality, as the spanking new 'break' command.
> >
> > Suggested-by: Stefan Beller <sbeller@google.com>
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> 
> If one wants to emulate this with the versions of Git that are
> currently deployed, would it be sufficient to insert "exec false"
> instead of "break"?

There is one crucial difference: the exit code.

If you are scripting around `git rebase -i` (and I do, heavily), then that
is quite a difference: who's to say that the rebase "failed" because of
that `exec false`, or if it failed another `exec` unexpectedly?

> The reason I am asking is *not* to imply that we do not need this
> new feature.  It is because I vaguely recall seeing a request to add
> 'pause' to the insn set and "exec false" was mentioned as a more
> general alternative long time ago.  I am trying to see if this is a
> recurring request/wish, because it would reinforce that this new
> feature would be a good addition if that is the case.
> 
> I suspect that "exec false" would give a message that looks like a
> complaint ("'false' failed so we are giving you control back to fix
> things" or something like that), and having a dedicated way to pause
> the execution without alarming the user is a good idea.
> 
> I think the earlier request asked for 'pause' (I didn't dig the list
> archive very carefully, though),

No need to: I mentioned it in the cover letter. Here is the link again,
for your convenience:
https://public-inbox.org/git/20180118183618.39853-3-sbeller@google.com/

> and 'stop' may also be a possible verb, but I tend to agree with this
> patch that 'break' is probably the best choice, simply because it begins
> with 'b' in the abbreviated form, a letter that is not yet used by
> others (unlike 'pause' or 'stop' that would want 'p' and 's' that are
> already taken)..
> 
> Here is a tangent, but I think the description of "-x <cmd>" in "git
> rebase --continue" should mention that a failing command would
> interrupt the sequencer.  That fact about "exec" command is given
> much later in the last part of the "interactive mode" section of the
> manual, so technically our docs are not being incomplete, but the
> current description is not helpful to those who are looking for
> substring "exec" from the beginning of the documentation to find out
> if the exit status of the command affects the way commits are
> replayed (which is what I was doing when imagining how users would
> emulate this feature with deployed versions of Git).
> 
> Perhaps something as simple as this...
> 
>  Documentation/git-rebase.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 0e20a66e73..0fc5a851b5 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -420,7 +420,8 @@ idea unless you know what you are doing (see BUGS below).
>  --exec <cmd>::
>  	Append "exec <cmd>" after each line creating a commit in the
>  	final history. <cmd> will be interpreted as one or more shell
> -	commands.
> +	commands, and interrupts the rebase session when it exits with
> +	non-zero status.

Good initial version. I would like it to be a bit more precise about who
exits with what status. How about this:

+	commands. Any command that fails will interrupt the rebase,
+	with exit code 1.

>  +
>  You may execute several commands by either using one instance of `--exec`
>  with several commands:
> 
> 
> Also, it seems that this has some interaction with the topics in
> flight; the added test does pass when queued on top of 'master', but
> fails when merged to 'pu'.  I didn't look into the details as I am
> not fully online yet.

I had a similar issue in a preliminary revision, and had to unset
GIT_EDITOR to fix it. Probably the culprit here is the same; I could
imagine that core.editor was set by another topic.

[... clicketiclick, debug debug debug, 1.5h later...]

Actually, this is not the problem. The problem is that the interactive
rebase exits with status 0 but does not leave a `stopped-sha` file behind,
and the builtin rebase mistakes that for a sign that it can clean up the
state dir.

However, we definitely do not want to leave that file, because it
indicates a fixup or squash with merge conflicts was left behind.

Taking a step back, it appears that we do a whole lot of work for nothing
in the case of the interactive rebase: it cleans up the state directory
itself already, and takes care of the autostash support, too.

So I will apply this fixup js/rebase-in-c-5.5-work-with-rebase-i-in-c:

-- snip --
fixup! builtin rebase: prepare for builtin rebase -i

The original patch worked, but overlooked the fact that `git
rebase--interactive` really wants to take care of finishing the rebase
itself.

While it was not harmful to try again, there was no directory to work
with, so no harm was done. Except in the case that an `edit` command was
processed, in which case we used the `stopped-sha` file as tell-tale
that we should not remove the state directory.

However, with the `break` command we do not have such a tell-tale. But
then, we don't really need one: the built-in `rebase--interactive` takes
care of clean-up itself. So we can just skip it in the built-in rebase.

While at it, remove the `case` arm for the interactive rebase that is
now skipped in favor of the short-cut to the built-in rebase.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 builtin/rebase.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/builtin/rebase.c b/builtin/rebase.c
index 99fd5d4017..2ca5fa1d74 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -410,6 +410,7 @@ static int run_specific_rebase(struct rebase_options *opts)
 			argv_array_push(&child.args, "--signoff");
 
 		status = run_command(&child);
+
 		goto finished_rebase;
 	}
 
@@ -475,10 +476,6 @@ static int run_specific_rebase(struct rebase_options *opts)
 		backend = "git-rebase--am";
 		backend_func = "git_rebase__am";
 		break;
-	case REBASE_INTERACTIVE:
-		backend = "git-rebase--interactive";
-		backend_func = "git_rebase__interactive";
-		break;
 	case REBASE_MERGE:
 		backend = "git-rebase--merge";
 		backend_func = "git_rebase__merge";
@@ -501,6 +498,8 @@ static int run_specific_rebase(struct rebase_options *opts)
 finished_rebase:
 	if (opts->dont_finish_rebase)
 		; /* do nothing */
+	else if (opts->type == REBASE_INTERACTIVE)
+		; /* interactive rebase cleans up after itself */
 	else if (status == 0) {
 		if (!file_exists(state_dir_path("stopped-sha", opts)))
 			finish_rebase(opts);
-- snap --

This fix-up seems to unbreak the `break` test case (pun intended)...

Ciao,
Dscho
Junio C Hamano Oct. 9, 2018, 3:59 a.m. UTC | #4
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Junio,
>
> On Fri, 5 Oct 2018, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
>> writes:
>> 
>> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
>> >
>> > The 'edit' command can be used to cherry-pick a commit and then
>> > immediately drop out of the interactive rebase, with exit code 0, to let
>> > the user amend the commit, or test it, or look around.
>>  ...
>> If one wants to emulate this with the versions of Git that are
>> currently deployed, would it be sufficient to insert "exec false"
>> instead of "break"?
>
> There is one crucial difference: the exit code.

OK, and it was good that you explicitly said "with exit code 0" in
the log message.  Together with the idea to update the doc I floated
earlier, this probably is worth documenting, too.

>> I think the earlier request asked for 'pause' (I didn't dig the list
>> archive very carefully, though),
>
> No need to: I mentioned it in the cover letter. Here is the link again,
> for your convenience:
> https://public-inbox.org/git/20180118183618.39853-3-sbeller@google.com/

No, you misunderstood.  I knew what message in the immediate past
triggered this patch and that wasn't what I "could have dug for but
didn't".  "The earlier request" I meant was another one I recall
that was made long time ago---that was what I "could have dug for
but didn't".

> Good initial version. I would like it to be a bit more precise about who
> exits with what status. How about this:

Sounds good.  It is likely that I'll either forget or will continue
to be too busy to pick textual pieces and assemble together myself,
so I'll leave it as a left over bit for somebody reading from the
sideline to send in a finished version if they care deeply enough
;-)

Thanks.
Junio C Hamano Oct. 9, 2018, 5:27 a.m. UTC | #5
Junio C Hamano <gitster@pobox.com> writes:

>> There is one crucial difference: the exit code.
>
> OK, and it was good that you explicitly said "with exit code 0" in
> the log message.  Together with the idea to update the doc I floated
> earlier, this probably is worth documenting, too.

Heh, I am becoming sloppy in reviewing.  The patch does not even
update any doc.

It is not a reason to reject the change (the change looks reasonably
simple and reviewers and those who have to look at the code to build
upon it would understand it in the current shape), but it is a
blocker for the change to be merged to 'next' and down.

Patch
diff mbox series

diff --git a/rebase-interactive.c b/rebase-interactive.c
index 0f4119cbae..78f3263fc1 100644
--- a/rebase-interactive.c
+++ b/rebase-interactive.c
@@ -14,6 +14,7 @@  void append_todo_help(unsigned edit_todo, unsigned keep_empty,
 "s, squash <commit> = use commit, but meld into previous commit\n"
 "f, fixup <commit> = like \"squash\", but discard this commit's log message\n"
 "x, exec <command> = run command (the rest of the line) using shell\n"
+"b, break = stop here (continue rebase later with 'git rebase --continue')\n"
 "d, drop <commit> = remove commit\n"
 "l, label <label> = label current HEAD with a name\n"
 "t, reset <label> = reset HEAD to a label\n"
diff --git a/sequencer.c b/sequencer.c
index 8dd6db5a01..b209f8af46 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1416,6 +1416,7 @@  enum todo_command {
 	TODO_SQUASH,
 	/* commands that do something else than handling a single commit */
 	TODO_EXEC,
+	TODO_BREAK,
 	TODO_LABEL,
 	TODO_RESET,
 	TODO_MERGE,
@@ -1437,6 +1438,7 @@  static struct {
 	{ 'f', "fixup" },
 	{ 's', "squash" },
 	{ 'x', "exec" },
+	{ 'b', "break" },
 	{ 'l', "label" },
 	{ 't', "reset" },
 	{ 'm', "merge" },
@@ -1964,7 +1966,7 @@  static int parse_insn_line(struct todo_item *item, const char *bol, char *eol)
 	padding = strspn(bol, " \t");
 	bol += padding;
 
-	if (item->command == TODO_NOOP) {
+	if (item->command == TODO_NOOP || item->command == TODO_BREAK) {
 		if (bol != eol)
 			return error(_("%s does not accept arguments: '%s'"),
 				     command_to_string(item->command), bol);
@@ -3293,6 +3295,9 @@  static int pick_commits(struct todo_list *todo_list, struct replay_opts *opts)
 			unlink(rebase_path_stopped_sha());
 			unlink(rebase_path_amend());
 			delete_ref(NULL, "REBASE_HEAD", NULL, REF_NO_DEREF);
+
+			if (item->command == TODO_BREAK)
+				break;
 		}
 		if (item->command <= TODO_SQUASH) {
 			if (is_rebase_i(opts))
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 25a77ee5cb..584604ee63 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -49,7 +49,7 @@  set_fake_editor () {
 		case $line in
 		squash|fixup|edit|reword|drop)
 			action="$line";;
-		exec*)
+		exec*|break)
 			echo "$line" | sed 's/_/ /g' >> "$1";;
 		"#")
 			echo '# comment' >> "$1";;
diff --git a/t/t3418-rebase-continue.sh b/t/t3418-rebase-continue.sh
index c145dbac38..185a491089 100755
--- a/t/t3418-rebase-continue.sh
+++ b/t/t3418-rebase-continue.sh
@@ -239,5 +239,14 @@  test_rerere_autoupdate -m
 GIT_SEQUENCE_EDITOR=: && export GIT_SEQUENCE_EDITOR
 test_rerere_autoupdate -i
 test_rerere_autoupdate --preserve-merges
+unset GIT_SEQUENCE_EDITOR
+
+test_expect_success 'the todo command "break" works' '
+	rm -f execed &&
+	FAKE_LINES="break exec_>execed" git rebase -i HEAD &&
+	test_path_is_missing execed &&
+	git rebase --continue &&
+	test_path_is_file execed
+'
 
 test_done