Re: [PATCH 4/4] doc: git-pull: clarify how to exit a conflicted merge
Show 19 quoted lines
> Le 7 oct. 2025 à 17:01, Julia Evans <julia@jvns.ca> 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
>>> <gitgitgadget@gmail.com> wrote:
>>>
>>> From: Julia Evans <julia@jvns.ca>
>>>
>>> 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.
Show 34 quoted lines
>>
>>> --- 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.