From: Ben Knoble Date: Fri, 10 Oct 2025 00:45:30 GMT Subject: Re: [PATCH 4/4] doc: git-pull: clarify how to exit a conflicted merge Message-ID: <6B75AE20-CF68-4C98-A49C-248E2C50A756@gmail.com> In-Reply-To: <74f8a51f-f62d-4f85-89b0-f701338c7550@app.fastmail.com> > Le 7 oct. 2025 à 17:01, Julia Evans 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 >>> wrote: >>> >>> From: Julia Evans >>> >>> 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.