git interactive rebase - edit vs break

Viewed 3181

I've tried googling this but wasn't able to find a satisfactory answer.

I'd like to know what the difference is between edit and break in the interactive mode of git rebase -i.

According to the comments, edit uses the commit, but stops for amending, while break stops at the specified location. But then what is the difference between:

# Scenario 1

pick a9ca198 commit #1
pick 15948d1 commit #2
edit 2dbe941 commit #3  // this will apply commit #3 and then stop.
pick 33c012d commit #4
# Scenario 2

pick a9ca198 commit #1
pick 15948d1 commit #2
pick 2dbe941 commit #3
break                   // this will stop after commit #3
pick 33c012d commit #4

I've tried them both and to me, they seem to be completely identical.

3 Answers

The documentation mentions:

To interrupt the rebase (just like an "edit" command would do, but without cherry-picking any commit first), use the "break" command.

In your case, the differences are:

  • with edit on commit 3, you can still amend the files content of commit 3 (after applying commit 3), commit (still commit 3, but modified/amended), and go on applying (cherry-picking) commit 4 on a git rebase --continue.
  • with break after commit 3, commit 4 will not be applied. And commit 3 is already applied (if you change the files at at point, add and commit, that would create a new commit, unless you do a git commit --amend).

So the main difference is:

  • edit: apply the commit 3, but allows you to modify the end result. Then resume and apply commit 4.
  • break: do not apply the commit 4 (apply it only when you resume the rebase)

If break is alone on its line, then yes, it can be similar to edit on commit 3, provided you do a git commit --amend (since commit 3 was already cherry-picked in the previous line)

But then the git rebase --continue (after the add+commit --amend) will stop, because of said break.

As DylanYoung puts it in the comments:

It allows you to break immediately after an exec or merge, which was not possible before.


Note: break was introduced with an interactive rebase in Git v1.5.3-rc0, June 2007, commit 1b1dce4.

But the command break alone is much more recent: Git v2.20.0-rc0, Oct. 2018, commit 71f8246

See commit 71f8246 (12 Oct 2018), and commit b8c0b21 (10 Oct 2018) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 789b1f7, 02 Nov 2018)

"git rebase -i" learned a new instruction ("insn"), 'break', that the user can insert in the to-do list.
Upon hitting it, the command returns control back to the user.

rebase -i: introduce the 'break' command

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.


See "Give me a break"... well, you gave me one:

Just wanted to express my gratitude for your idea to introduce the break command in git rebase -i's todo list. I use it all the time now.

Before that, I was using x bash, and ended up doing git rebase --continue in that shell in many cases, which didn't end up so well when I terminated said shell (just an error message, though, nothing actually broke as a consequence). This feature is a blessing.

Or:

'x bash' will start another shell, that seems an odd thing to do.

I have been using 'x false' to generate an error exit status to interrupt the rebase and drop into the current shell.
Then 'git rebase --continue' to resume.

b is much shorter to type than x false (and I also cannot tyop it late at night as x flase, although that would have the same effect, I guess, of stopping the interactive rebase).

One thing that I use break for that edit cannot do is apply a fixup and then do something else, like update a code review.

E.g. if I have

pick commit1 feature x
pick commit2 feature y
pick commit3 fixup for feature x

I can

$ git rebase --interactive
pick commit1 feature x
fixup commit3 fixup for feature x
break
pick commit2 feature y

then

$ command-to-update-cr
$ git rebase --continue

Note that you could use exec for the same purpose, but I prefer the control I get from getting dropped into the command line.

In the example you provide, you are correct. Using break after pick is identical to just using edit. It doesn't make sense to use break this way. Where break becomes useful is when it follows squash, fixup, merge, or exec.

This is explained in the commit message that introduced the break command:

rebase -i: introduce the 'break' command

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.

Related