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.
Just right-click on the commit you want to edit and select Interactively Rebase from Here… Select reword on the commit and click Start Rebasing. Edit the commit message and click Resume Rebasing.
Interactive rebase in Git is a tool that provides more manual control of your history revision process. When using interactive rebase, you will specify a point on your branch's history, and then you will be presented with a list of commits up until that point.
To do this, simply delete all commits and actions (i.e. all lines not starting with the # sign) and the rebase will be aborted!
Changing Multiple Commit Messages You can run rebase interactively by adding the -i option to git rebase . You must indicate how far back you want to rewrite commits by telling the command which commit to rebase onto.
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:
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
.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
ormerge
, 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
' commandThe '
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 ingit rebase -i
's todo list. I use it all the time now.Before that, I was using
x bash
, and ended up doinggit 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 thanx false
(and I also cannot tyop it late at night asx 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With