From: Phillip Wood Date: Mon, 11 Aug 2025 13:02:26 GMT Subject: Re: [PATCH v4 2/5] doc: git rebase: dedup merge conflict discussion Message-ID: <14d6589c-87a1-4d08-84c1-a9398f6cb8d8@gmail.com> In-Reply-To: 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 `` 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