On 11/08/2025 09:46, Patrick Steinhardt wrote:
On Sat, Aug 09, 2025 at 01:14:14AM +0000, Julia Evans via GitGitGadget wrote:
-It is possible that a merge failure will prevent this process from being
-completely automatic. You will have to resolve any such merge failure
-and run `git rebase --continue`. Another option is to bypass the commit
-that caused the merge failure with `git rebase --skip`. To check out the
-original `<branch>` and remove the `.git/rebase-apply` working files, use
-the command `git rebase --abort` instead.
-
If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
will be skipped and warnings will be issued (if the 'merge' backend is
We lose the bit about `.git/rebase-apply`, but I don't think that's a
bad thing. The user shouldn't have to care how exactly a rebase looks on
disk.
Exactly, we don't want to encourage the user to poke about in the state
directory. Also ".git/rebase-apply" wont exist unless the user requested
the apply backend so mentioning it is misleading (the default is
".git/rebase-merge" these days).
Thanks
Phillip
