Implement "Edit commit" by breaking after current commit #2451
Conversation
We need this because the next commit is going to make use of the "break" interactive rebase instruction, which was added in 2.20.
Instead of rebasing from the commit below the current one and then setting the current one to "edit", we rebase from the current one and insert a "break" after it. In most cases the behavior is exactly the same as before, except that the new method also works if the current commit is a merge commit. This is useful if you want to create a new commit at the very beginning of your branch (by editing the last commit before your branch).
| } | ||
| | ||
| if version.IsOlderThan(2, 0, 0) { | ||
| if version.IsOlderThan(2, 20, 0) { |
There was a problem hiding this comment.
@jesseduffield Not sure you'll agree with this. Personally I find it a bit insane to support nine-year-old git versions, so I'd have no problem with this change; but if you object, I think it should be possible to fall back to the old way of editing a commit if the git version is older than 2.20. Let me know what you prefer.
There was a problem hiding this comment.
I'm fine with it. 2.0 was arbitrary in the first place
There was a problem hiding this comment.
OK, great. I added a commit to revert a compatibility fix that was added for supporting versions older than 2.7, which we now no longer need; @Ryooooooga, please have a look.
Uffizzi Preview Environment |
| This is great, I'm all for it. We currently raise an error upon trying to start an interactive rebase from the first commit i.e.: // pkg/commands/git_commands/rebase.go:165 if len(commits) <= baseIndex { return nil, "", errors.New(self.Tr.CannotRebaseOntoFirstCommit) }Is this check no longer required thanks to this PR? If so, would be good to remove that guard and add an integration test showing that this works from the first commit |
Removing the guard is not possible, we still need it to guard against rewording the first commit, which is still not possible. (Side note: when rewording, you get the error message only after having typed the new commit message, it would be nice if we would error out before that.) But I added an integration test for editing the first commit, which is now indeed possible. |
Since we now require git 2.20, we don't need this any more. This reverts commit 7c5f339.
stefanhaller force-pushed the edit-by-breaking-after-current-commit branch from 87020e5 to ac9515d Compare
I take that back, this test doesn't belong here. The fact that this branch also allows editing the first commit is a bit of a coincidence. I dropped the test again from here. I created another PR which is independent from this one, which allows all interactive rebase operations down to the initial commit; I added the test there (and a few others): #2453 |
| Tested it locally, all works fine. Thanks for making this! |
3 participants
Instead of rebasing from the commit below the current one and then setting the
current one to "edit", we rebase from the current one and insert a "break" after
it. In most cases the behavior is exactly the same as before, except that the
new method also works if the current commit is a merge commit. This is useful if
you want to create a new commit at the very beginning of your branch (before the
first commit of your branch), if the last commit before that is a merge.
go run scripts/cheatsheet/main.go generate)docs/Config.md) have been updated if necessary