Subject: Re: [PATCH 4/4] doc: git-pull: clarify how to exit a conflicted merge

From: Ben Knoble <[email-masked]>
Date: Thu, 9 Oct 2025 20:45:30 -0400

> Le 7 oct. 2025 à 17:01, Julia Evans <[email-masked]> a écrit :
> 
> 
> 
>> On Wed, Sep 24, 2025, at 4:29 PM, D. Ben Knoble wrote:
>>> On Tue, Sep 23, 2025 at 3:48 PM Julia Evans via GitGitGadget
>>> <[email-masked]> wrote:
>>> 
>>> From: Julia Evans <[email-masked]>
>>> 
>>> From user feedback:
>>> 
>>> - One user is confused about why `git reset --merge`
>>>  (why not just `git reset`?). Handle this by mentioning
>>>  `git merge --abort` and `git reset --abort` instead, which have a
>>>  more obvious meaning.
>> 
>> "git reset --merge" _can_ be helpful when merging, but won't fully
>> abort a rebase. Great.

While fiddling around: turns out reset’s merge flag does abort the merge properly. TMTOWTDI, I suppose. 

>> 
>>> --- a/Documentation/git-pull.adoc
>>> +++ b/Documentation/git-pull.adoc
>>> @@ -30,15 +30,9 @@ branch. There are 4 main options for integrating the remote branch:
>>> You can also set the configuration options `pull.rebase`, `pull.squash`,
>>> or `pull.ff` with your preferred behaviour.
>>> 
>>> -In Git 1.7.0 or later, to cancel a conflicting merge, use
>>> -`git reset --merge`.  *Warning*: In older versions of Git, running 'git pull'
>>> -with uncommitted changes is discouraged: while possible, it leaves you
>>> -in a state that may be hard to back out of in the case of a conflict.
>>> -
>>> -If any of the remote changes overlap with local uncommitted changes,
>>> -the merge will be automatically canceled and the work tree untouched.
>>> -It is generally best to get any local changes in working order before
>>> -pulling or stash them away with linkgit:git-stash[1].
>>> +If there's a merge conflict during the merge or rebase that you don't
>>> +want to handle, you can safely abort it with `git merge --abort` or `git
>>> +--rebase abort`.
>> 
>> This information is also mentioned in the advice given by conflicts
>> (and git status), so while I originally wondered if we need to say "to
>> know which to use, run…", I now think we can trust users to know
>> whether they asked for a merge or rebase and read the advice/git
>> status output when they don't.
>> 
>> Hah, just kidding. Nobody* reads that output. But I still don't think
>> it's worth muddying here, because the same folks are unlikely to see
>> the help here, right? Or maybe we say "Information in `git status`
>> will summarize these options for you." ?
> 
> I think it's a nice way to reiterate that `git pull` is running a merge or
> rebase under the hood, but if folks feel strongly that this isn't relevant
> I'd be happy to remove the `git merge --abort` / `git rebase --abort` note.

I’d probably prefer to keep the pull->{merge,rebase} implication. I just want « how do I know which one » to be clear.