Re: [PATCH v3 1/6] doc: add new gitmergeconflicts man page

["Julia Evans" <julia@jvns.ca>]

On Tue, Oct 13, 2026, at 7:07 AM, Patrick Steinhardt wrote:
> On Mon, Oct 12, 2026 at 02:53:10PM +0000, Julia Evans via GitGitGadget wrote:
>> diff --git a/Documentation/gitmergeconflicts.adoc b/Documentation/gitmergeconflicts.adoc
>> new file mode 100644
>> index 0000000000..3c6eaaddf8
>> --- /dev/null
>> +++ b/Documentation/gitmergeconflicts.adoc
>> @@ -0,0 +1,330 @@
>> +gitmergeconflicts(7)
>> +====================
>> +
>> +NAME
>> +----
>> +gitmergeconflicts - Guide to handling merge conflicts
>> +
>> +DESCRIPTION
>> +-----------
>> +
>> +Merge conflicts can happen during a `git merge`, `git rebase`, `git
>> +cherry-pick`, `git pull`, `git revert`, or any other command that does
>> +a merge. All of those commands use the same merge algorithm, and the
>> +process for resolving a merge conflict is always very similar.
>> +
>> +There are 3 ways to handle a merge conflict:
>> +
>> +* Resolve the conflict. (see <<resolve,HOW TO RESOLVE A MERGE CONFLICT>>
>> +  below for details)
>> +* Stop the operation and return your branch to its original state
>> +  with the appropriate `--abort` command, for example `git merge --abort`
>> +  or `git rebase --abort`. See <<git_status,EXAMPLE: GIT STATUS OUTPUT>> below
>> +  for how to find the command to run.
>> +* Or (if you're in a multi-step rebase or cherry-pick) skip the problematic
>> +  commit with the appropriate `--skip` command
>
> Nit: the punctuation is a bit inconsistent, where the second bullet
> point has a trailing punctuation mark but the other two don't.

Thanks, tried to make this a bit more consistent. I think I have some slightly
idiosyncratic personal rules for punctuation in bulleted lists that I don't
feel very attached to.

>> +WHAT IS A MERGE CONFLICT?
>> +-------------------------
>> +
>> +When Git merges two commits together, it looks at the changes that
>> +each side has made and combines those changes. For example, if one side
>> +edited lines 1-5 of `hello.py` and the other side edited lines 20-25 of
>> +the same file, then it can easily combine them since there's no overlap.
>> +
>> +But if both sides edited overlapping lines of the same file (for example
>> +one side edited lines 1-5 and the other edited lines 3-6), Git will
>> +not try to guess how to combine those changes. This is called a "merge
>> +conflict".
>> +
>> +When this happens, Git shows you both sides' edits and asks you to pick
>> +how to resolve them. It:
>> +
>> +* Stages all of the files which were successfully merged
>> +* For the files with conflicts, it marks them as conflicted, puts both
>> +  sides' edits in the file, and leaves <<markers, merge conflict markers>>
>> +  that you need to resolve.
>
> Same nit here.

>> +[NOTE]
>> +================================
>> +Even if Git successfully merges both sides with no conflicts, it's
>> +possible to end up with code that doesn't work. For example, this can
>> +happen if one side renames a function, and the other side adds a call to
>> +the old function. This is called a "semantic merge conflict".
>> +================================
>
> Good callout. We may also want to spell out the consequence of this:
> "You should always verify the result of a merge regardless of whether or
> not it has resulted in a conflict.".

I think we should let people use their own judgment about how to use this
information.

>> +[[resolve]]
>> +HOW TO RESOLVE A MERGE CONFLICT
>> +-------------------------------
>> +
>> +The process for resolving a merge conflict is:
>> +
>> +1. Run `git status` to get a list of files with merge conflicts
>> +2. For each one, find the conflict markers
>> +   (the `<<<<<<<`, `=======`, `>>>>>>>`) and edit the code to
>> +   fix the conflict
>> +3. Run `git add FILENAME` for each file to mark the conflict as resolved
>> +4. Run the appropriate `--continue` command to continue the operation
>> +   that was interrupted by the conflict, for example `git merge --continue`
>> +   or `git rebase --continue`. See <<git_status,EXAMPLE: GIT STATUS OUTPUT>>
>> +   below for how to find the command to run.
>
> Same nit regarding punctuation. Or is this actually a thing, where you
> add punctuation in case it's multiple sentences but not in the case
> where it's a single sentence, only? Maybe this is just me not being a
> native speaker.
>
>> +[[tools]]
>> +TOOLS FOR HANDLING MERGE CONFLICTS
>> +----------------------------------
>> +
>> +Here are some ways to get extra context while handling a merge conflict:
>> +
>> +* There are many graphical "merge tools" for Git, which will normally
>> +  show you the different versions of the code side by side.
>> +  If you have a mergetool configured, `git mergetool` will launch it.
>> +  See also `merge.tool` in linkgit:git-config[1] for a list of
>> +  the mergetools Git supports.
>> +
>> +* You can set the configuration variable `merge.conflictstyle=diff3`.
>> +  See <<diff3,DIFF3>> below for more.
>> +
>> +* `git log --merge -p <filename>`  will list all commits which
>
> Should we spell this out as `--patch` instead? That's way easier to grep
> in the manpage in case the reader is curious what the option does.

Good idea, will do.

>> +[NOTE]
>> +================================
>> +`zdiff3` is an alternative to `diff3` that makes the merge conflict
>> +shorter by making it more ambiguous.
>> +================================
>
> "making it more ambiguous" reads rather curious. Should we maybe take
> inspiration from its documentation and instead say "by removing matching
> lines on the two sides from the beginning or end of a conflict region"?

Hmm, I've gone back and forth a lot on how to explain zdiff3, from

1. Here's how it works and here's an example to illustrate
2. You shouldn't use it
3. You may want to use it but be aware that it's ambiguous
4. Here's more info about about how it works

I think Junio's diff3 example does a really good job of making it clear 
why diff3 might be useful. The previous zdiff3 example I had that talked
about the pros and cons of using zdiff3 didn't feel very compelling to me
and I don't know how to write a good one. I think a good example
probably does exist, but we might actually need multiple examples
(both to show how zdiff can be useful and to show the issues).

Perhaps given that we seem to not necessarily want to recommend
zdiff3, we can just not mention zdiff3 for now and add it back later if/when
we feel more confident about how to explain it. I'll try just deleting the note.

>> +[[ours]]
>> +"OURS" AND "THEIRS"
>> +-------------------
>> +
>> +Sometimes during a merge conflict, Git will use the terms "ours" and
>> +"theirs" (or "us" and "them"). For example, `git status` might say that
>> +a file was `deleted by us`.
>> +
>> +"Ours" and "theirs" are both commits: "ours" is the current
>> +`HEAD` commit, and "theirs" is the other side being merged.
>
> They may not always be commits, but they are always tree-ishs. But I
> think it's fine to leave this as-is anyway, as the normal user is never
> going to encounter cases where it's not in fact a commit. And when they
> do they probably don't need this manpage anyway.

Interesting, I didn't know it could be something other than a commit.

>
> Other than this handful of nits I'm happy with this version, thanks!
>
> Patrick

thanks for the review!