{"thread":{"id":"66387","subject":"[PATCH 0/7] [doc] Add new page on merge conflicts","startedAt":"2026-09-24T14:44:24Z","lastAt":"2026-10-05T19:11:21Z","messageCount":44,"participants":["Julia Evans via GitGitGadget","Junio C Hamano","Jeff King","D. Ben Knoble","Julia Evans","Ben Knoble","Patrick Steinhardt"],"isPatch":true,"patchVersion":1,"patchTotal":7},"messages":[{"id":"553192","messageId":"pull.2237.git.1790261062.gitgitgadget@gmail.com","threadId":"66387","inReplyTo":null,"subject":"[PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"Julia Evans via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-24T14:44:15Z","receivedAt":"2026-09-24T14:44:24Z","isPatch":true,"body":"Handling merge conflicts is difficult, and currently Git's guidance on merge\nconflicts isn't giving users the information they need to navigate the\nprocess. As usual, the process I used to write this was to collect comments\nfrom Git users on the existing documentation, and then address those issues.\nI listed the specific issues we're aiming to solve in the first commit\nmessage in the series.\n\nThis patch series introduces a new manual page, gitmergeconflicts, which\nexplains the process of explaining a merge conflict with examples. It also\nlinks to that new page from the commands which can cause merge conflicts,\ninstead of trying to reexplain the process every time.\n\nThis is a pretty big change, so here's a list of things I'm still\nconsidering in the hopes that it'll help with the discussion:\n\n * I wrote that git commit does the same thing as git merge --continue\n during a git merge , but I'm not sure if that's always true.\n * Not 100% sure that the explanation of diff3 vs zdiff3 is correct\n * Right now we're listing git merge, git revert, git rebase, git\n cherry-pick, and git pull as commands that can cause merge conflicts. I\n believe that git apply and git am can also result in conflicts when\n applying a patch, though it's a bit complicated because applying a patch\n is a different operation than doing a 3-way merge and the tools available\n for dealing with it are a different. My thought right now is to avoid the\n issue of applying patches for now (because it's a whole can of worms) and\n instead just try to not imply that this is necessarily an exhaustive\n list. Also if/when the git rebase --squash changes land, then we'd need\n to add git history to this list.\n * Instead of creating a new page, I considered using an include to have a\n \"handling merge conflicts\" section in git rebase, git merge, etc. Merge\n conflict resolution is complex and it's very useful to be able to include\n examples: this version ended up at ~300 lines and I think that's too big\n of an include, especially for short man pages like cherry-pick\n * Explaining what \"ours\" and \"theirs\" mean was one of the hardest parts of\n writing this. From polling Git users in one of my many informal Mastodon\n polls about Git, my understanding is that Git users are actually\n relatively unlikely to actually reason about what \"ours\" and \"theirs\"\n mean when dealing with a merge conflict, and that most people prefer to\n get more context instead, for example by using a mergetool or by using\n diff3 or zdiff3. I heard a lot of \"I can never remember which is which I\n so I don't even try\". So I put the information about what \"ours\" and\n \"theirs\" mean relatively far down the page (with some cross-references),\n so that it's easily available but not the main focus.\n * I removed a couple of mentions of the various _HEAD references. It's hard\n for me to know exactly where they belong because I personally have never\n used MERGE_HEAD, REBASE_HEAD, ORIG_HEAD, CHERRY_PICK_HEAD etc, and I\n don't know how they're meant to be used. From some quick unscientific\n polling (at https://social.jvns.ca/@b0rk/117320011885941855), it seems\n like most Git users have never used them either (and folks who do use a\n *_HEAD reference mainly seem to use FETCH_HEAD which isn't relevant\n here), so from that perspective it seems important to avoid emphasizing\n them too much. The git revert man page doesn't mention REVERT_HEAD and\n git rebase only mentions REBASE_HEAD in passing. Of course they're all\n explained in gitrevisions(7) which might be the best place for them.\n * I'm still not sure what the SYNOPSIS section is for in a \"guide\" man page\n which is not about a specific Git command (what is the user intended to\n use it for?). I tried to leave it out but the CI said it was required.\n\nThanks to Lobo, Adam Svahn, Louis Vanier, David Turner, Ben Zanin, Salih,\nand about 12 others who gave feedback on both the original git merge man\npage, as well as the proposed improvements.\n\nJulia Evans (7):\n [doc] Add new gitmergeconflicts man page\n [doc] git-merge: link to new merge conflicts guide\n [doc] git-rebase: link to new merge conflicts guide\n [doc] git-revert: link to new merge conflicts guide\n [doc] git-cherry-pick: link to new merge conflicts guide\n [doc] git-pull: link to new merge conflicts guide\n [doc] ignore conflict markers in gitmergeconflicts.adoc\n\n .gitattributes | 1 +\n Documentation/Makefile | 1 +\n Documentation/git-cherry-pick.adoc | 23 +--\n Documentation/git-merge.adoc | 125 +-----------\n Documentation/git-pull.adoc | 3 +-\n Documentation/git-rebase.adoc | 13 +-\n Documentation/git-revert.adoc | 5 +\n Documentation/gitmergeconflicts.adoc | 294 +++++++++++++++++++++++++++\n Documentation/meson.build | 1 +\n 9 files changed, 320 insertions(+), 146 deletions(-)\n create mode 100644 Documentation/gitmergeconflicts.adoc\n\n\nbase-commit: 3bc0341126508f78f5869cbfc0005e987efdf0c7\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2237%2Fjvns%2Fmerge-conflicts-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2237/jvns/merge-conflicts-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/2237\n-- \ngitgitgadget\n"},{"id":"553193","messageId":"ad4853dc36cdb883c9a8dc6bda747a5ea318e7a8.1790261062.git.gitgitgadget@gmail.com","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"[PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Julia Evans via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-24T14:44:16Z","receivedAt":"2026-09-24T14:44:25Z","isPatch":true,"body":"From: Julia Evans \n\nIntroduce a new page, `gitmergeconflicts`, that explains the process of\nhandling a merge conflict in a way that addresses the following issues,\nwhich came from feedback from Git users on the current explanation of\nmerge conflicts in the `git merge` man page:\n\n- The process for resolving a merge conflict is only explained in the\n `git merge` man page, even though there are several other commands\n which can result in conflicts\n- Sometimes we use \"ours\" and \"theirs\" to refer to the two sides of\n the merge conflicts and sometimes we use HEAD and MERGE_HEAD. It should\n be consistent. Also the terms \"ours\" and \"theirs\" are not explained.\n Similarly, it says \"The part before the `=======` is typically your\n side...\", but doesn't explain what \"typically\" means.\n- It introduces the merge format using an analogy to RCS, which very few\n Git users have ever used\n- In \"The only clean-ups you need are to reset the index file to the\n `HEAD` commit to reverse 2. and to clean up working tree changes made\n by 2. and 3.\", it's not clear to users what \"2\" and \"3\" are supposed\n to mean\n- It uses a cultural reference (\"Conflict resolution is hard; let's go\n shopping.\") which is confusing or unfamiliar to some people. I think it\n would be clearer for users to use a code example instead.\n- It doesn't explain the difference between diff3 and zdiff3\n- It sometimes uses the term \"area\" and sometimes uses the term \"hunk\"\n\nAlso document the unified `--abort`, `--continue` workflow in one\nplace, since it's a really nice example of a place Git has a consistent\ninterface between similar commands.\n\nCo-Authored-By: Marie Claire LeBlanc Flanagan \nSigned-off-by: Julia Evans \n---\n Documentation/Makefile | 1 +\n Documentation/gitmergeconflicts.adoc | 294 +++++++++++++++++++++++++++\n Documentation/meson.build | 1 +\n 3 files changed, 296 insertions(+)\n create mode 100644 Documentation/gitmergeconflicts.adoc\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex f8dea4b395..bc49641dda 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -58,6 +58,7 @@ MAN7_TXT += gitdiffcore.adoc\n MAN7_TXT += giteveryday.adoc\n MAN7_TXT += gitfaq.adoc\n MAN7_TXT += gitglossary.adoc\n+MAN7_TXT += gitmergeconflicts.adoc\n MAN7_TXT += gitpacking.adoc\n MAN7_TXT += gitnamespaces.adoc\n MAN7_TXT += gitremote-helpers.adoc\ndiff --git a/Documentation/gitmergeconflicts.adoc b/Documentation/gitmergeconflicts.adoc\nnew file mode 100644\nindex 0000000000..612b683e40\n--- /dev/null\n+++ b/Documentation/gitmergeconflicts.adoc\n@@ -0,0 +1,294 @@\n+gitmergeconflicts(7)\n+====================\n+\n+NAME\n+----\n+gitmergeconflicts - Guide to handling merge conflicts\n+\n+\n+SYNOPSIS\n+--------\n+Guide to handling merge conflicts\n+\n+\n+DESCRIPTION\n+-----------\n+\n+Merge conflicts can happen during a `git merge`, `git rebase`, `git\n+cherry-pick`, `git pull`, or `git revert`. All of those commands use\n+the same merge algorithm, and the process for resolving a merge conflict\n+is always very similar.\n+\n+The most common ways to handle a merge conflict are:\n+\n+* Resolve the conflict. (see <>\n+ below for details)\n+* Or stop the operation and return your branch to its original state\n+ with the appropriate `--abort` command, for example `git merge --abort`\n+ or `git rebase --abort`. See <> below\n+ for how to find the command to run.\n+\n+\n+[[markers]]\n+MERGE CONFLICT MARKERS\n+----------------------\n+\n+Merge conflicts happen when both of the sides being merged edit the same\n+area of a file. When this happens, Git will update the conflicted file\n+to include merge conflict markers `<<<<<<<`, `=======`, and `>>>>>>>`.\n+For example, here's a merge conflict where both sides edited a list of\n+fruits in different ways:\n+\n+----\n+FRUITS = [\n+ \"apple\",\n+<<<<<<< HEAD\n+ \"cherry\",\n+=======\n+ \"banana\",\n+>>>>>>> add-fruit\n+ \"mango\",\n+ \"orange\",\n+]\n+----\n+\n+The code from one side of the merge conflict is between `<<<<<<<` and\n+`=======`, and the code for the other side is between `=======` and\n+`>>>>>>>`. See <> below for a full explanation\n+of which side is which.\n+\n+\n+[[resolve]]\n+HOW TO RESOLVE A MERGE CONFLICT\n+-------------------------------\n+\n+The process for resolving a merge conflict is:\n+\n+1. Run `git status` to get a list of files with merge conflicts\n+2. For each one, find the conflict markers\n+ (the `<<<<<<<`, `=======`, `>>>>>>>`) and edit the code to\n+ fix the conflict\n+3. Run `git add FILENAME` for each file to mark the conflict as resolved\n+4. Run the appropriate `--continue` command to continue the operation\n+ that was interrupted by the conflict, for example `git merge --continue`\n+ or `git rebase --continue`. See <>\n+ below for how to find the command to run.\n++\n+Note: During a `git merge`, `git commit` and `git merge --continue` do\n+the the same thing.\n+\n+\n+[[example]]\n+EXAMPLE OF RESOLVING A MERGE CONFLICT\n+-------------------------------------\n+\n+If you see this in your code during a merge conflict:\n+\n+----\n+FRUITS = [\n+ \"apple\",\n+<<<<<<< HEAD\n+ \"cherry\",\n+ \"mango\",\n+=======\n+ \"banana\",\n+ \"mango\",\n+>>>>>>> add-fruit\n+ \"orange\",\n+]\n+----\n+\n+Then you might edit that part of the code like this,\n+which includes the fruits from both sides of the conflict:\n+\n+----\n+FRUITS = [\n+ \"apple\",\n+ \"banana\",\n+ \"cherry\",\n+ \"mango\",\n+ \"orange\",\n+]\n+----\n+\n+\n+[[tools]]\n+TOOLS FOR HANDLING MERGE CONFLICTS\n+----------------------------------\n+\n+Here are some ways to get extra context while handling a merge conflict:\n+\n+* There are many graphical \"merge tools\" for Git, which will normally\n+ show you the different versions of the code side by side.\n+ If you have a mergetool configured, `git mergetool` will launch it.\n+ See also `merge.tool` in linkgit:git-config[1] for a list of\n+ the mergetools Git supports.\n+\n+* You can set the configuration option `merge.conflictstyle=diff3`.\n+ See <> below for more.\n+\n+* Look at the original files. `git show :1:filename` shows the\n+ common ancestor, `git show :2:filename` shows the \"ours\"\n+ version, and `git show :3:filename` shows the \"theirs\"\n+ version.\n+\n+Here are some ways to track your progress while handling a conflict:\n+\n+* Use `git status` to get a list of files with conflicts\n+\n+* Use `git diff --check` to make sure you haven't left any merge\n+ conflict markers in a file by accident. It will print \"leftover\n+ conflict marker\" if it finds any.\n+\n+* Use `git diff AUTO_MERGE` to show what changes you've made so far to\n+ resolve the conflicts.\n+\n+[[git_status]]\n+EXAMPLE: GIT STATUS OUTPUT\n+--------------------------\n+\n+When you're in a merge conflict, you can find out what commands to run\n+to handle the conflict by running `git status`.\n+\n+For example, this `git status` output tells you that:\n+\n+* `git rebase --abort` will safely bring your branch back to its\n+ original state\n+* you should run `git rebase --continue` when you're done resolving all\n+ the conflicts\n+* there's one file left with conflicts in it: `fruits.py`\n+\n+----\n+$ git status\n+You are currently rebasing branch 'main' on '58a9fcc'.\n+ (fix conflicts and then run \"git rebase --continue\")\n+ (use \"git rebase --skip\" to skip this patch)\n+ (use \"git rebase --abort\" to check out the original branch)\n+\n+Unmerged paths:\n+ (use \"git restore --staged ...\" to unstage)\n+ (use \"git add ...\" to mark resolution)\n+ both modified: fruits.py\n+----\n+\n+\n+[[diff3]]\n+DIFF3 AND ZDIFF3\n+----------------\n+\n+By default, Git doesn't include the original code when formatting\n+a merge conflict. To include the original code, you can set the\n+configuration option `merge.conflictstyle` to `diff3` or `zdiff3`.\n+This extra context can make it much easier to understand what's\n+happening in a merge conflict.\n+\n+Here's an example of what a merge conflict would look like when using\n+`diff3`. It shows, in order, the \"ours\" side of the conflict, the\n+original code (`\"mangoooo\"`), and the \"theirs\" side of the\n+conflict. With this view, you can see that both sides fixed the spelling\n+mistake in \"mango\", and each added one fruit to the list.\n+\n+----\n+FRUITS = [\n+ \"apple\",\n+<<<<<<< HEAD\n+ \"cherry\",\n+ \"mango\",\n+||||||| 1c22e48\n+ \"mangoooo\",\n+=======\n+ \"banana\",\n+ \"mango\",\n+>>>>>>> add-fruit\n+ \"orange\",\n+]\n+----\n+\n+Here's the same example using `zdiff3`. `zdiff3` takes lines that are\n+shared between both sides (the `\"mango\"` line) and moves them outside\n+the conflicted area. This makes the conflicted area shorter, but the\n+downside is that it's impossible to tell if `\"mango\"` was part of the\n+original list of fruits or not.\n+\n+----\n+FRUITS = [\n+ \"apple\",\n+<<<<<<< HEAD\n+ \"cherry\",\n+||||||| 1c22e48\n+ \"mangoooo\",\n+=======\n+ \"banana\",\n+>>>>>>> add-fruit\n+ \"mango\",\n+ \"orange\",\n+]\n+----\n+\n+\n+[[ours]]\n+\"OURS\" AND \"THEIRS\"\n+-------------------\n+\n+Git refers to the first part of a merge conflict (between `<<<<<<<`\n+and `=======`) as \"ours\" and the second part (between `=======` and\n+`>>>>>>>`) as \"theirs\".\n+\n+Normally, \"ours\" is the commit that was checked out before you started\n+the merge, and \"theirs\" is the other commit.\n+\n+But when the merge conflict was caused by a `git rebase`, it's the\n+opposite: \"theirs\" is the commit that was checked out before you started\n+the merge. This is because under the hood, `git rebase main` checks out\n+the `main` commit first before doing the merge operation.\n+\n+These terms in Git all mean the same thing when dealing with a merge\n+conflict:\n+\n+* \"common ancestor\", \"base\", and \"stage 1\"\n+* \"ours\", \"us\", \"stage 2\", and `HEAD`\n+* \"theirs\", \"them\", and \"stage 3\"\n+\n+[[automerge]]\n+Example of using `AUTO_MERGE`\n+-----------------------------\n+\n+`git diff AUTO_MERGE` will show what changes you've made so far to\n+resolve conflicts. `AUTO_MERGE` is a reference that Git creates during a\n+merge. It contains the result of running the merge algorithm.\n+\n+For example, if we resolved the conflict the way we did in the\n+<>, the diff would look like this:\n+\n+----\n+ FRUITS = [\n+ \"apple\",\n+-<<<<<<< HEAD\n+- \"cherry\",\n+-=======\n+ \"banana\",\n+->>>>>>> add-fruit\n++ \"cherry\",\n+ \"mango\",\n+ \"orange\",\n+]\n+----\n+\n+[NOTE]\n+`AUTO_MERGE` is only set if you're using the default Git merge algorithm.\n+\n+\n+SEE ALSO\n+--------\n+\n+linkgit:git-revert[1]\n+linkgit:git-merge[1]\n+linkgit:git-rebase[1]\n+linkgit:git-cherry-pick[1]\n+linkgit:git-pull[1]\n+linkgit:git-diff[1]\n+\n+GIT\n+---\n+\n+Part of the linkgit:git[1] suite\ndiff --git a/Documentation/meson.build b/Documentation/meson.build\nindex f4854f802d..51647957e0 100644\n--- a/Documentation/meson.build\n+++ b/Documentation/meson.build\n@@ -202,6 +202,7 @@ manpages = {\n 'gitfaq.adoc' : 7,\n 'gitglossary.adoc' : 7,\n 'gitpacking.adoc' : 7,\n+ 'gitmergeconflicts.adoc' : 7,\n 'gitnamespaces.adoc' : 7,\n 'gitremote-helpers.adoc' : 7,\n 'gitrevisions.adoc' : 7,\n-- \ngitgitgadget\n\n"},{"id":"553194","messageId":"a1686a2d82ef9357ecff07c1247092d3dd5ecf95.1790261062.git.gitgitgadget@gmail.com","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"[PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Julia Evans via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-24T14:44:17Z","receivedAt":"2026-09-24T14:44:27Z","isPatch":true,"body":"From: Julia Evans \n\nAll of the info about merge conflicts has been moved to the new guide\n\nSigned-off-by: Julia Evans \n---\n Documentation/git-merge.adoc | 125 +----------------------------------\n 1 file changed, 3 insertions(+), 122 deletions(-)\n\ndiff --git a/Documentation/git-merge.adoc b/Documentation/git-merge.adoc\nindex a055384ad6..5b7b41cd10 100644\n--- a/Documentation/git-merge.adoc\n+++ b/Documentation/git-merge.adoc\n@@ -49,7 +49,8 @@ a log message from the user describing the changes. Before the operation,\n A merge stops if there's a conflict that cannot be resolved\n automatically or if `--no-commit` was provided when initiating the\n merge. At that point you can run `git merge --abort` or `git merge\n---continue`.\n+--continue`. See linkgit:gitmergeconflicts[7]\n+(or `git help mergeconflicts`) for a guide to handling merge conflicts.\n \n `git merge --abort` will abort the merge process and try to reconstruct\n the pre-merge state. However, if there were uncommitted changes when the\n@@ -231,127 +232,6 @@ git merge v1.2.3^0\n git merge --ff-only v1.2.3\n ----\n \n-HOW CONFLICTS ARE PRESENTED\n----------------------------\n-\n-During a merge, the working tree files are updated to reflect the result\n-of the merge. Among the changes made to the common ancestor's version,\n-non-overlapping ones (that is, you changed an area of the file while the\n-other side left that area intact, or vice versa) are incorporated in the\n-final result verbatim. When both sides made changes to the same area,\n-however, Git cannot randomly pick one side over the other, and asks you to\n-resolve it by leaving what both sides did to that area.\n-\n-By default, Git uses the same style as the one used by the \"merge\" program\n-from the RCS suite to present such a conflicted hunk, like this:\n-\n-------------\n-Here are lines that are either unchanged from the common\n-ancestor, or cleanly resolved because only one side changed,\n-or cleanly resolved because both sides changed the same way.\n-<<<<<<< yours:sample.txt\n-Conflict resolution is hard;\n-let's go shopping.\n-=======\n-Git makes conflict resolution easy.\n->>>>>>> theirs:sample.txt\n-And here is another line that is cleanly resolved or unmodified.\n-------------\n-\n-The area where a pair of conflicting changes happened is marked with markers\n-+<<<<<<<+, `=======`, and +>>>>>>>+. The part before the `=======`\n-is typically your side, and the part afterwards is typically their side.\n-\n-The default format does not show what the original said in the conflicting\n-area. You cannot tell how many lines are deleted and replaced with\n-Barbie's remark on your side. The only thing you can tell is that your\n-side wants to say it is hard and you'd prefer to go shopping, while the\n-other side wants to claim it is easy.\n-\n-An alternative style can be used by setting the `merge.conflictStyle`\n-configuration variable to either `diff3` or `zdiff3`. In `diff3`\n-style, the above conflict may look like this:\n-\n-------------\n-Here are lines that are either unchanged from the common\n-ancestor, or cleanly resolved because only one side changed,\n-<<<<<<< yours:sample.txt\n-or cleanly resolved because both sides changed the same way.\n-Conflict resolution is hard;\n-let's go shopping.\n-||||||| base:sample.txt\n-or cleanly resolved because both sides changed identically.\n-Conflict resolution is hard.\n-=======\n-or cleanly resolved because both sides changed the same way.\n-Git makes conflict resolution easy.\n->>>>>>> theirs:sample.txt\n-And here is another line that is cleanly resolved or unmodified.\n-------------\n-\n-while in `zdiff3` style, it may look like this:\n-\n-------------\n-Here are lines that are either unchanged from the common\n-ancestor, or cleanly resolved because only one side changed,\n-or cleanly resolved because both sides changed the same way.\n-<<<<<<< yours:sample.txt\n-Conflict resolution is hard;\n-let's go shopping.\n-||||||| base:sample.txt\n-or cleanly resolved because both sides changed identically.\n-Conflict resolution is hard.\n-=======\n-Git makes conflict resolution easy.\n->>>>>>> theirs:sample.txt\n-And here is another line that is cleanly resolved or unmodified.\n-------------\n-\n-In addition to the +<<<<<<<+, `=======`, and +>>>>>>>+ markers, it uses\n-another +|||||||+ marker that is followed by the original text. You can\n-tell that the original just stated a fact, and your side simply gave in to\n-that statement and gave up, while the other side tried to have a more\n-positive attitude. You can sometimes come up with a better resolution by\n-viewing the original.\n-\n-\n-HOW TO RESOLVE CONFLICTS\n-------------------------\n-\n-After seeing a conflict, you can do two things:\n-\n- * Decide not to merge. The only clean-ups you need are to reset\n- the index file to the `HEAD` commit to reverse 2. and to clean\n- up working tree changes made by 2. and 3.; `git merge --abort`\n- can be used for this.\n-\n- * Resolve the conflicts. Git will mark the conflicts in\n- the working tree. Edit the files into shape and\n- `git add` them to the index. Use `git commit` or\n- `git merge --continue` to seal the deal. The latter command\n- checks whether there is a (interrupted) merge in progress\n- before calling `git commit`.\n-\n-You can work through the conflict with a number of tools:\n-\n- * Use a mergetool. `git mergetool` to launch a graphical\n- mergetool which will work through the merge with you.\n-\n- * Look at the diffs. `git diff` will show a three-way diff,\n- highlighting changes from both the `HEAD` and `MERGE_HEAD`\n- versions. `git diff AUTO_MERGE` will show what changes you've\n- made so far to resolve textual conflicts.\n-\n- * Look at the diffs from each branch. `git log --merge -p `\n- will show diffs first for the `HEAD` version and then the\n- `MERGE_HEAD` version.\n-\n- * Look at the originals. `git show :1:filename` shows the\n- common ancestor, `git show :2:filename` shows the `HEAD`\n- version, and `git show :3:filename` shows the `MERGE_HEAD`\n- version.\n-\n-\n EXAMPLES\n --------\n \n@@ -406,6 +286,7 @@ linkgit:git-reset[1],\n linkgit:git-diff[1], linkgit:git-ls-files[1],\n linkgit:git-add[1], linkgit:git-rm[1],\n linkgit:git-mergetool[1]\n+linkgit:gitmergeconflicts[7]\n \n GIT\n ---\n-- \ngitgitgadget\n\n"},{"id":"553195","messageId":"128d69e482687d05aa854e51843a42c14a315d5b.1790261062.git.gitgitgadget@gmail.com","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"[PATCH 3/7] [doc] git-rebase: link to new merge conflicts guide","fromName":"Julia Evans via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-24T14:44:18Z","receivedAt":"2026-09-24T14:44:28Z","isPatch":true,"body":"From: Julia Evans \n\nRemove some of the detail about how to handle a merge conflict, since\nit's explained in detail in the new guide, and there probably isn't\nenough detail anyway.\n\nLeave the steps since rebase is special and has a `--skip` option which\nthe other commands which cause merge conflicts don't have.\n\nSigned-off-by: Julia Evans \n---\n Documentation/git-rebase.adoc | 13 +++++++++----\n 1 file changed, 9 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\nindex f6c22d1598..da70aff498 100644\n--- a/Documentation/git-rebase.adoc\n+++ b/Documentation/git-rebase.adoc\n@@ -46,10 +46,7 @@ If there is a merge conflict during this process, `git rebase` will stop at the\n first problematic commit and leave conflict markers. If this happens, you can do\n one of these things:\n \n-1. Resolve the conflict. You can use `git diff` to find the markers (<<<<<<)\n- and make edits to resolve the conflict. For each file you edit, you need to\n- tell Git that the conflict has been resolved. You can mark the conflict as\n- resolved with `git add `. After resolving all of the conflicts,\n+1. Resolve the conflict. After resolving all of the conflicts,\n you can continue the rebasing process with\n \n git rebase --continue\n@@ -62,6 +59,9 @@ one of these things:\n \n git rebase --skip\n \n+See linkgit:gitmergeconflicts[7] (or `git help mergeconflicts`)\n+for a full guide to handling merge conflicts.\n+\n If you don't specify an `` to rebase onto, the upstream configured in\n `branch..remote` and `branch..merge` options will be used (see\n linkgit:git-config[1] for details) and the `--fork-point` option is\n@@ -1284,6 +1284,11 @@ include::includes/cmd-config-section-all.adoc[]\n include::config/rebase.adoc[]\n include::config/sequencer.adoc[]\n \n+SEE ALSO\n+--------\n+\n+linkgit:gitmergeconflicts[7]\n+\n GIT\n ---\n Part of the linkgit:git[1] suite\n-- \ngitgitgadget\n\n"},{"id":"553196","messageId":"ab459231e024c5c254ee7f336fcac2e249309bd4.1790261062.git.gitgitgadget@gmail.com","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"[PATCH 4/7] [doc] git-revert: link to new merge conflicts guide","fromName":"Julia Evans via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-24T14:44:19Z","receivedAt":"2026-09-24T14:44:29Z","isPatch":true,"body":"From: Julia Evans \n\nSigned-off-by: Julia Evans \n---\n Documentation/git-revert.adoc | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/Documentation/git-revert.adoc b/Documentation/git-revert.adoc\nindex ffba365e63..0a84447a47 100644\n--- a/Documentation/git-revert.adoc\n+++ b/Documentation/git-revert.adoc\n@@ -31,6 +31,10 @@ both will discard uncommitted changes in your working directory.\n See \"Reset, restore and revert\" in linkgit:git[1] for the differences\n between the three commands.\n \n+If there have been new commits since the reverted conflict, there may\n+be a merge conflict. See linkgit:gitmergeconflicts[7]\n+(or `git help mergeconflicts`) for a guide to handling merge conflicts.\n+\n OPTIONS\n -------\n ...::\n@@ -162,6 +166,7 @@ include::config/revert.adoc[]\n SEE ALSO\n --------\n linkgit:git-cherry-pick[1]\n+linkgit:gitmergeconflicts[7]\n \n GIT\n ---\n-- \ngitgitgadget\n\n"},{"id":"553197","messageId":"03a6b43b5803e6bd9ebba1a49c34cb42202a7f44.1790261062.git.gitgitgadget@gmail.com","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"[PATCH 5/7] [doc] git-cherry-pick: link to new merge conflicts guide","fromName":"Julia Evans via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-24T14:44:20Z","receivedAt":"2026-09-24T14:44:31Z","isPatch":true,"body":"From: Julia Evans \n\nRemove the discussion of merge conflicts and replace it with a link to\nthe guide.\n\nSigned-off-by: Julia Evans \n---\n Documentation/git-cherry-pick.adoc | 23 ++++-------------------\n 1 file changed, 4 insertions(+), 19 deletions(-)\n\ndiff --git a/Documentation/git-cherry-pick.adoc b/Documentation/git-cherry-pick.adoc\nindex f4cd8b9db7..d93829600b 100644\n--- a/Documentation/git-cherry-pick.adoc\n+++ b/Documentation/git-cherry-pick.adoc\n@@ -19,25 +19,9 @@ Given one or more existing commits, apply the change each one\n introduces, recording a new commit for each. This requires your\n working tree to be clean (no modifications from the HEAD commit).\n \n-When it is not obvious how to apply a change, the following\n-happens:\n-\n-1. The current branch and `HEAD` pointer stay at the last commit\n- successfully made.\n-2. The `CHERRY_PICK_HEAD` ref is set to point at the commit that\n- introduced the change that is difficult to apply, unless the\n- `--no-commit` option was given.\n-3. Paths in which the change applied cleanly are updated both\n- in the index file and in your working tree.\n-4. For conflicting paths, the index file records up to three\n- versions, as described in the \"TRUE MERGE\" section of\n- linkgit:git-merge[1]. The working tree files will include\n- a description of the conflict bracketed by the usual\n- conflict markers `<<<<<<<` and `>>>>>>>`.\n-5. No other modifications are made.\n-\n-See linkgit:git-merge[1] for some hints on resolving such\n-conflicts.\n+When it is not obvious how to apply a change, there may\n+be a merge conflict. See linkgit:gitmergeconflicts[7]\n+(or `git help mergeconflicts`) for a guide to handling merge conflicts.\n \n OPTIONS\n -------\n@@ -259,6 +243,7 @@ $ git cherry-pick -Xpatience topic^ <4>\n SEE ALSO\n --------\n linkgit:git-revert[1]\n+linkgit:gitmergeconflicts[7]\n \n GIT\n ---\n-- \ngitgitgadget\n\n"},{"id":"553198","messageId":"d3904f0ca7ad0c2274d642dfc72b863647df487f.1790261062.git.gitgitgadget@gmail.com","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"[PATCH 6/7] [doc] git-pull: link to new merge conflicts guide","fromName":"Julia Evans via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-24T14:44:21Z","receivedAt":"2026-09-24T14:44:32Z","isPatch":true,"body":"From: Julia Evans \n\nSigned-off-by: Julia Evans \n---\n Documentation/git-pull.adoc | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-pull.adoc b/Documentation/git-pull.adoc\nindex 88f4fd3926..73f6d460bb 100644\n--- a/Documentation/git-pull.adoc\n+++ b/Documentation/git-pull.adoc\n@@ -38,7 +38,8 @@ or `pull.ff` with your preferred behaviour.\n \n If there's a merge conflict during the merge or rebase that you don't\n want to handle, you can safely abort it with `git merge --abort` or\n-`git rebase --abort`.\n+`git rebase --abort`. See linkgit:gitmergeconflicts[7]\n+(or `git help mergeconflicts`) for a guide to handling merge conflicts.\n \n OPTIONS\n -------\n-- \ngitgitgadget\n\n"},{"id":"553199","messageId":"4505fdc9a6dec37296952107c90947e43f39bae4.1790261062.git.gitgitgadget@gmail.com","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"[PATCH 7/7] [doc] ignore conflict markers in gitmergeconflicts.adoc","fromName":"Julia Evans via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-24T14:44:22Z","receivedAt":"2026-09-24T14:44:33Z","isPatch":true,"body":"From: Julia Evans \n\nSigned-off-by: Julia Evans \n---\n .gitattributes | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/.gitattributes b/.gitattributes\nindex 26490ad60a..0a0fc950b1 100644\n--- a/.gitattributes\n+++ b/.gitattributes\n@@ -14,6 +14,7 @@ CODE_OF_CONDUCT.md -whitespace\n /t/oid-info/* text eol=lf\n /Documentation/git-merge.adoc conflict-marker-size=32\n /Documentation/git-merge-file.adoc conflict-marker-size=32\n+/Documentation/gitmergeconflicts.adoc conflict-marker-size=32\n /Documentation/gitk.adoc conflict-marker-size=32\n /Documentation/user-manual.adoc conflict-marker-size=32\n /t/t????-*.sh conflict-marker-size=32\n-- \ngitgitgadget\n"},{"id":"553239","messageId":"xmqqa4p61j4w.fsf@gitster.g","threadId":"66387","inReplyTo":"ad4853dc36cdb883c9a8dc6bda747a5ea318e7a8.1790261062.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-24T20:36:47Z","receivedAt":"2026-09-24T20:36:50Z","isPatch":true,"body":"\"Julia Evans via GitGitGadget\" writes:\n\n> Documentation/Makefile | 1 +\n> Documentation/gitmergeconflicts.adoc | 294 +++++++++++++++++++++++++++\n> Documentation/meson.build | 1 +\n> 3 files changed, 296 insertions(+)\n> create mode 100644 Documentation/gitmergeconflicts.adoc\n>\n> diff --git a/Documentation/Makefile b/Documentation/Makefile\n> index f8dea4b395..bc49641dda 100644\n> --- a/Documentation/Makefile\n> +++ b/Documentation/Makefile\n> @@ -58,6 +58,7 @@ MAN7_TXT += gitdiffcore.adoc\n> MAN7_TXT += giteveryday.adoc\n> MAN7_TXT += gitfaq.adoc\n> MAN7_TXT += gitglossary.adoc\n> +MAN7_TXT += gitmergeconflicts.adoc\n\nThis unfortunately needs to be accompanied with a matching change to\nhelp the other build system.\n\nYou probably want to move your change to set conflict-marker-size\nfor this new file to this step, not at the end as if an\nafterthought.\n\n\n Documentation/meson.build | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git c/Documentation/meson.build w/Documentation/meson.build\nindex 51647957e0..10b0637991 100644\n--- c/Documentation/meson.build\n+++ w/Documentation/meson.build\n@@ -201,6 +201,7 @@ manpages = {\n 'giteveryday.adoc' : 7,\n 'gitfaq.adoc' : 7,\n 'gitglossary.adoc' : 7,\n+ 'gitmergeconflicts.adoc' : 7,\n 'gitpacking.adoc' : 7,\n 'gitmergeconflicts.adoc' : 7,\n 'gitnamespaces.adoc' : 7,\n"},{"id":"553243","messageId":"xmqqo6dmz4p2.fsf@gitster.g","threadId":"66387","inReplyTo":"xmqqa4p61j4w.fsf@gitster.g","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-24T22:04:41Z","receivedAt":"2026-09-24T22:04:43Z","isPatch":true,"body":"Junio C Hamano writes:\n\n> This unfortunately needs to be accompanied with a matching change to\n> help the other build system.\n\nI did get a build failure due to meson, but apparently not due to\nthis step in the 7-patch series.\n\n> You probably want to move your change to set conflict-marker-size\n> for this new file to this step, not at the end as if an\n> afterthought.\n\nThis still stands, though.\n\nSorry, a wrong patch and a false alarm.\n\n>\n>\n> Documentation/meson.build | 1 +\n> 1 file changed, 1 insertion(+)\n>\n> diff --git c/Documentation/meson.build w/Documentation/meson.build\n> index 51647957e0..10b0637991 100644\n> --- c/Documentation/meson.build\n> +++ w/Documentation/meson.build\n> @@ -201,6 +201,7 @@ manpages = {\n> 'giteveryday.adoc' : 7,\n> 'gitfaq.adoc' : 7,\n> 'gitglossary.adoc' : 7,\n> + 'gitmergeconflicts.adoc' : 7,\n> 'gitpacking.adoc' : 7,\n> 'gitmergeconflicts.adoc' : 7,\n> 'gitnamespaces.adoc' : 7,\n"},{"id":"553247","messageId":"xmqq33uyz3yp.fsf@gitster.g","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-24T22:20:30Z","receivedAt":"2026-09-24T22:20:33Z","isPatch":true,"body":"\"Julia Evans via GitGitGadget\" writes:\n\n> Julia Evans (7):\n> [doc] Add new gitmergeconflicts man page\n> [doc] git-merge: link to new merge conflicts guide\n> [doc] git-rebase: link to new merge conflicts guide\n> [doc] git-revert: link to new merge conflicts guide\n> [doc] git-cherry-pick: link to new merge conflicts guide\n> [doc] git-pull: link to new merge conflicts guide\n> [doc] ignore conflict markers in gitmergeconflicts.adoc\n\nWith this merged, 'seen' seems to fail\n\n\t$ make check-docs\n\nwith these lines at the end\n\n ...\n MKDIR -p .build/lint-docs/doc-style/includes\n LINT DOCSTYLE includes/cmd-config-section-all.adoc\n LINT DOCSTYLE includes/cmd-config-section-rest.adoc\n GEN lint-docs-manpages\n no link: gitmergeconflicts\n\nThanks.\n"},{"id":"553252","messageId":"20260924233726.GB765100@coredump.intra.peff.net","threadId":"66387","inReplyTo":"xmqq33uyz3yp.fsf@gitster.g","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-09-24T23:37:26Z","receivedAt":"2026-09-24T23:37:27Z","isPatch":true,"body":"On Thu, Sep 24, 2026 at 03:20:30PM -0700, Junio C Hamano wrote:\n\n> \"Julia Evans via GitGitGadget\" writes:\n> \n> > Julia Evans (7):\n> > [doc] Add new gitmergeconflicts man page\n> > [doc] git-merge: link to new merge conflicts guide\n> > [doc] git-rebase: link to new merge conflicts guide\n> > [doc] git-revert: link to new merge conflicts guide\n> > [doc] git-cherry-pick: link to new merge conflicts guide\n> > [doc] git-pull: link to new merge conflicts guide\n> > [doc] ignore conflict markers in gitmergeconflicts.adoc\n> \n> With this merged, 'seen' seems to fail\n> \n> \t$ make check-docs\n> \n> with these lines at the end\n> \n> ...\n> MKDIR -p .build/lint-docs/doc-style/includes\n> LINT DOCSTYLE includes/cmd-config-section-all.adoc\n> LINT DOCSTYLE includes/cmd-config-section-rest.adoc\n> GEN lint-docs-manpages\n> no link: gitmergeconflicts\n\nWeirdly applying Julia's patches myself did not result in the same\nerror. It's only when they're merged to seen. Ah. It's due to\nta/command-list-guides-sync-lint, which isn't yet in master.\n\nI think that is giving us a good signal, though. The guide should be\nmentioned in command-list.txt, so that it is linked from git(1). See\nc655855559 (doc: git: list gitdatamodel(7) as a concept guide,\n2026-09-05) for some prior art.\n\n-Peff\n"},{"id":"553295","messageId":"CALnO6CA_=OsznkQ4iT0vBMWf3L=bmVKMBdk1MTHQdaKEcKwn4g@mail.gmail.com","threadId":"66387","inReplyTo":"pull.2237.git.1790261062.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-25T16:25:44Z","receivedAt":"2026-09-25T16:25:57Z","isPatch":true,"body":"A big thank you for working on this.\n\nOn Thu, Sep 24, 2026 at 10:46 AM Julia Evans via GitGitGadget\n wrote:\n>\n> Handling merge conflicts is difficult, and currently Git's guidance on merge\n> conflicts isn't giving users the information they need to navigate the\n> process. As usual, the process I used to write this was to collect comments\n> from Git users on the existing documentation, and then address those issues.\n> I listed the specific issues we're aiming to solve in the first commit\n> message in the series.\n>\n> This patch series introduces a new manual page, gitmergeconflicts, which\n> explains the process of explaining a merge conflict with examples. It also\n> links to that new page from the commands which can cause merge conflicts,\n> instead of trying to reexplain the process every time.\n>\n> This is a pretty big change, so here's a list of things I'm still\n> considering in the hopes that it'll help with the discussion:\n>\n> * I wrote that git commit does the same thing as git merge --continue\n> during a git merge , but I'm not sure if that's always true.\n\nSee also discussion in\nhttps://lore.kernel.org/git/CABPp-BEQSx4m3BcT28CpVGCtsH75+x3gmv4OJz_ecLVLx+kBWg@mail.gmail.com/T/#t\n\n> * Right now we're listing git merge, git revert, git rebase, git\n> cherry-pick, and git pull as commands that can cause merge conflicts. I\n> believe that git apply and git am can also result in conflicts when\n> applying a patch, though it's a bit complicated because applying a patch\n> is a different operation than doing a 3-way merge and the tools available\n> for dealing with it are a different. My thought right now is to avoid the\n> issue of applying patches for now (because it's a whole can of worms) and\n> instead just try to not imply that this is necessarily an exhaustive\n> list.\n\nI think that's a good approach!\n\n> Also if/when the git rebase --squash changes land, then we'd need\n> to add git history to this list.\n\nI imagine you meant history squash? I also thought that history had\npunted on how to deal with conflicts (rejecting any operation which\ncreates them) for now, since we don't have 1st-class conflicts à la\nJujutsu.\n\n> * Instead of creating a new page, I considered using an include to have a\n> \"handling merge conflicts\" section in git rebase, git merge, etc. Merge\n> conflict resolution is complex and it's very useful to be able to include\n> examples: this version ended up at ~300 lines and I think that's too big\n> of an include, especially for short man pages like cherry-pick\n\nSensible. I have often wished some of our includes were actually links\nto separate documents, to keep overall document size down.\n\n> * Explaining what \"ours\" and \"theirs\" mean was one of the hardest parts of\n> writing this. From polling Git users in one of my many informal Mastodon\n> polls about Git, my understanding is that Git users are actually\n> relatively unlikely to actually reason about what \"ours\" and \"theirs\"\n> mean when dealing with a merge conflict, and that most people prefer to\n> get more context instead, for example by using a mergetool or by using\n> diff3 or zdiff3. I heard a lot of \"I can never remember which is which I\n> so I don't even try\". So I put the information about what \"ours\" and\n> \"theirs\" mean relatively far down the page (with some cross-references),\n> so that it's easily available but not the main focus.\n\nI think the biggest reason to (ahem) reason about these is if one\nwants to restore --{ours,theirs} or restart and try again with a merge\nstrategy -s {ours,theirs} [rare] or merge strategy option -X\n{ours,theirs} [less rare].\n\nBut, leaving it out of focus makes sense to me!\n\n> * I removed a couple of mentions of the various _HEAD references. It's hard\n> for me to know exactly where they belong because I personally have never\n> used MERGE_HEAD, REBASE_HEAD, ORIG_HEAD, CHERRY_PICK_HEAD etc, and I\n> don't know how they're meant to be used.\n\nMy most frequently use is \"git show REBASE_HEAD\" (which is what \"git\nrebase --show-current-patch\" does, albeit with more typing). :shrug:\n\n-- \nD. Ben Knoble\n"},{"id":"553299","messageId":"CALnO6CDdoqE2hyZMJg6OZkzNtcnjNXRz=HO4q6cZVpF_wbTXyw@mail.gmail.com","threadId":"66387","inReplyTo":"a1686a2d82ef9357ecff07c1247092d3dd5ecf95.1790261062.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-25T16:36:10Z","receivedAt":"2026-09-25T16:36:24Z","isPatch":true,"body":"Hi Julia,\n\nOn Thu, Sep 24, 2026 at 10:46 AM Julia Evans via GitGitGadget\n wrote:\n>\n> From: Julia Evans \n>\n> All of the info about merge conflicts has been moved to the new guide\n\n> Among the changes made to the common ancestor's version,\n> -non-overlapping ones (that is, you changed an area of the file while the\n> -other side left that area intact, or vice versa) are incorporated in the\n> -final result verbatim. When both sides made changes to the same area,\n> -however, Git cannot randomly pick one side over the other, and asks you to\n> -resolve it by leaving what both sides did to that area.\n\n> - * Look at the diffs from each branch. `git log --merge -p `\n> - will show diffs first for the `HEAD` version and then the\n> - `MERGE_HEAD` version.\n\nI think these are both valuable pieces of information we have lost in\nthe new guide (unless I misremember just having read patch 1 :).\n\nThe first explains a bit more about what a conflict *is*. Maybe that's\nold-hat nowadays, but I think it could be nice to keep a statement\nabout why conflicts exist.\n\nThe second is a very useful way to get more context to help resolve\nconflicts! I have an alias \"conflict = log --oneline --graph\n--left-right --boundary --merge\" for a similar purpose, and I think\nthe new guide should help folks discover --merge. Often I can get a\nbetter sense of how to resolve conflicts by comparing the original\nchanges on each side, or I might at least know who to ask about what\nto do.\n\n-- \nD. Ben Knoble\n"},{"id":"553303","messageId":"2f71028f-d58e-400f-a02e-7a25c032d889@app.fastmail.com","threadId":"66387","inReplyTo":"CALnO6CDdoqE2hyZMJg6OZkzNtcnjNXRz=HO4q6cZVpF_wbTXyw@mail.gmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-09-25T16:59:35Z","receivedAt":"2026-09-25T16:59:59Z","isPatch":true,"body":"\n\nOn Fri, Sep 25, 2026, at 12:36 PM, D. Ben Knoble wrote:\n> Hi Julia,\n>\n> On Thu, Sep 24, 2026 at 10:46 AM Julia Evans via GitGitGadget\n> wrote:\n>>\n>> From: Julia Evans \n>>\n>> All of the info about merge conflicts has been moved to the new guide\n>\n>> Among the changes made to the common ancestor's version,\n>> -non-overlapping ones (that is, you changed an area of the file while the\n>> -other side left that area intact, or vice versa) are incorporated in the\n>> -final result verbatim. When both sides made changes to the same area,\n>> -however, Git cannot randomly pick one side over the other, and asks you to\n>> -resolve it by leaving what both sides did to that area.\n>\n>> - * Look at the diffs from each branch. `git log --merge -p `\n>> - will show diffs first for the `HEAD` version and then the\n>> - `MERGE_HEAD` version.\n>\n> I think these are both valuable pieces of information we have lost in\n> the new guide (unless I misremember just having read patch 1 :).\n>\n> The first explains a bit more about what a conflict *is*. Maybe that's\n> old-hat nowadays, but I think it could be nice to keep a statement\n> about why conflicts exist.\n\nWill think about this!\n\n> The second is a very useful way to get more context to help resolve\n> conflicts! I have an alias \"conflict = log --oneline --graph\n> --left-right --boundary --merge\" for a similar purpose, and I think\n> the new guide should help folks discover --merge. Often I can get a\n> better sense of how to resolve conflicts by comparing the original\n> changes on each side, or I might at least know who to ask about what\n> to do.\n\nThanks, I meant to flag this: the reason I deleted it was really\njust that I couldn't understand what `git log --merge -p ` did\nfrom the documentation and so I removed it until I could figure it out.\nI thought that `--merge` meant that it had something to do with merge\ncommits, but upon further investigation it looks like that's not true, and\nthat `--merges` is related to merge commits, `--merge` is something\ntotally different which is relevant any time there's a conflict\n\nMy best guess now is that it would make sense to include this\nunder \"Tools to get more context\". Maybe something like this:\n\n> `git log --merge -p ` will print out all commits which\n> caused the merge conflict for ``, and the diff\n> of how they changed the file. \n\n(\"which caused the merge conflict for\" is a little more vague, but\nI'm trying to convey the intent, and hopefully folks can look at\n`man git log` if they want to know the specifics)\n\nThis does sound really useful.\n"},{"id":"553304","messageId":"xmqqpky1uu6t.fsf@gitster.g","threadId":"66387","inReplyTo":"03a6b43b5803e6bd9ebba1a49c34cb42202a7f44.1790261062.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 5/7] [doc] git-cherry-pick: link to new merge conflicts guide","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-25T17:17:30Z","receivedAt":"2026-09-25T17:17:40Z","isPatch":true,"body":"\"Julia Evans via GitGitGadget\" writes:\n\n> From: Julia Evans \n>\n> Remove the discussion of merge conflicts and replace it with a link to\n> the guide.\n>\n> Signed-off-by: Julia Evans \n> ---\n> Documentation/git-cherry-pick.adoc | 23 ++++-------------------\n> 1 file changed, 4 insertions(+), 19 deletions(-)\n>\n> diff --git a/Documentation/git-cherry-pick.adoc b/Documentation/git-cherry-pick.adoc\n> index f4cd8b9db7..d93829600b 100644\n> --- a/Documentation/git-cherry-pick.adoc\n> +++ b/Documentation/git-cherry-pick.adoc\n> @@ -19,25 +19,9 @@ Given one or more existing commits, apply the change each one\n> introduces, recording a new commit for each. This requires your\n> working tree to be clean (no modifications from the HEAD commit).\n> \n> -When it is not obvious how to apply a change, the following\n> -happens:\n> -\n> -1. The current branch and `HEAD` pointer stay at the last commit\n> - successfully made.\n> -2. The `CHERRY_PICK_HEAD` ref is set to point at the commit that\n> - introduced the change that is difficult to apply, unless the\n> - `--no-commit` option was given.\n> -3. Paths in which the change applied cleanly are updated both\n> - in the index file and in your working tree.\n> -4. For conflicting paths, the index file records up to three\n> - versions, as described in the \"TRUE MERGE\" section of\n> - linkgit:git-merge[1]. The working tree files will include\n> - a description of the conflict bracketed by the usual\n> - conflict markers `<<<<<<<` and `>>>>>>>`.\n> -5. No other modifications are made.\n> -\n> -See linkgit:git-merge[1] for some hints on resolving such\n> -conflicts.\n> +When it is not obvious how to apply a change, there may\n> +be a merge conflict. See linkgit:gitmergeconflicts[7]\n> +(or `git help mergeconflicts`) for a guide to handling merge conflicts.\n\nThe new document may explain how to resolve conflicts, but are the\ndetails removed from here that are specific to the 'cherry-pick'\noperation also covered there?\n\nFor example, during a difficult cherry-pick, it is often handy to be\nable to run 'git show CHERRY_PICK_HEAD', but now users are not told\nabout the pseudo-ref, which seems like a real loss.\n\nThe fact that cleanly auto-resolved contents for paths are recorded\nin the index may be shared with all other merge-like operations,\nand it need not be part of the \"how to resolve a conflicted\nmerge-like operation\" recipe, but users need to be assured that this\nis what happens somewhere in the documentation set. The list\nremoved here served that purpose for this specific command, but it\nis now gone.\n\nI do not recall offhand whether we explicitly tell our users that\nall merge-like operations update the index with cleanly auto-resolved\nresults and only leave conflicts to be hand-resolved by the user,\nbut even if we did so elsewhere, I do not see any reference to that\nin the existing text of the 'cherry-pick' manual, nor does this\npatch series add such a link. At least item #2 and #3 should be\nkept in the list, I think. A better alternative might be to add\nyour new reference, and shorten the description given in item #4,\nand leave everything else as before.\n\nThanks.\n\n> \n> OPTIONS\n> -------\n> @@ -259,6 +243,7 @@ $ git cherry-pick -Xpatience topic^ <4>\n> SEE ALSO\n> --------\n> linkgit:git-revert[1]\n> +linkgit:gitmergeconflicts[7]\n> \n> GIT\n> ---\n"},{"id":"553307","messageId":"xmqqld8purb8.fsf@gitster.g","threadId":"66387","inReplyTo":"2f71028f-d58e-400f-a02e-7a25c032d889@app.fastmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-25T18:19:39Z","receivedAt":"2026-09-25T18:19:41Z","isPatch":true,"body":"\"Julia Evans\" writes:\n\n> Thanks, I meant to flag this: the reason I deleted it was really\n> just that I couldn't understand what `git log --merge -p ` did\n> from the documentation and so I removed it until I could figure it out.\n\nIt looks at the index to figure out which paths we got conflicts on,\nand then does \"git log -p \". You can\ngive a pathspec from the command line to further limit the output.\n\n>> `git log --merge -p ` will print out all commits which\n>> caused the merge conflict for ``, and the diff\n>> of how they changed the file. \n\nIf you _know_ which exact single file you are interested in, there\nis not much you gain from the \"--merge\" option. \"--left-right\"\noption may be a lot more useful there. It let's you see which side\nof the merge gave you what changes.\n"},{"id":"553314","messageId":"7EF35E41-8DB6-49B4-BFC6-6BE335047E60@gmail.com","threadId":"66387","inReplyTo":"xmqqld8purb8.fsf@gitster.g","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-25T19:32:34Z","receivedAt":"2026-09-25T19:32:49Z","isPatch":true,"body":"\n> Le 25 sept. 2026 à 14:19, Junio C Hamano a écrit :\n> \n> \"Julia Evans\" writes:\n> \n>> Thanks, I meant to flag this: the reason I deleted it was really\n>> just that I couldn't understand what `git log --merge -p ` did\n>> from the documentation and so I removed it until I could figure it out.\n> \n> It looks at the index to figure out which paths we got conflicts on,\n> and then does \"git log -p \". You can\n> give a pathspec from the command line to further limit the output.\n\nThis explanation omits the manual’s “HEAD…” argument\nthat the merge option implies, which is important for\nunderstanding the option and my alias ;)"},{"id":"553315","messageId":"C66B019E-9107-49BA-B54A-6B82BF11CB77@gmail.com","threadId":"66387","inReplyTo":"2f71028f-d58e-400f-a02e-7a25c032d889@app.fastmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-25T19:34:09Z","receivedAt":"2026-09-25T19:34:22Z","isPatch":true,"body":"\n> Le 25 sept. 2026 à 12:59, Julia Evans a écrit :\n> \n> \n> \n>> On Fri, Sep 25, 2026, at 12:36 PM, D. Ben Knoble wrote:\n>> Hi Julia,\n\n[snip]\n\n>> The second is a very useful way to get more context to help resolve\n>> conflicts! I have an alias \"conflict = log --oneline --graph\n>> --left-right --boundary --merge\" for a similar purpose, and I think\n>> the new guide should help folks discover --merge. Often I can get a\n>> better sense of how to resolve conflicts by comparing the original\n>> changes on each side, or I might at least know who to ask about what\n>> to do.\n> \n> Thanks, I meant to flag this: the reason I deleted it was really\n> just that I couldn't understand what `git log --merge -p ` did\n> from the documentation and so I removed it until I could figure it out.\n> I thought that `--merge` meant that it had something to do with merge\n> commits, but upon further investigation it looks like that's not true, and\n> that `--merges` is related to merge commits, `--merge` is something\n> totally different which is relevant any time there's a conflict\n> \n> My best guess now is that it would make sense to include this\n> under \"Tools to get more context\". Maybe something like this:\n> \n>> `git log --merge -p ` will print out all commits which\n>> caused the merge conflict for ``, and the diff\n>> of how they changed the file.\n> \n> (\"which caused the merge conflict for\" is a little more vague, but\n> I'm trying to convey the intent, and hopefully folks can look at\n> `man git log` if they want to know the specifics)\n> \n> This does sound really useful.\n\nThat reads well enough for me! Thanks. "},{"id":"553334","messageId":"xmqqjyo9t30c.fsf@gitster.g","threadId":"66387","inReplyTo":"7EF35E41-8DB6-49B4-BFC6-6BE335047E60@gmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-25T21:49:55Z","receivedAt":"2026-09-25T21:49:59Z","isPatch":true,"body":"Ben Knoble writes:\n\n>> Le 25 sept. 2026 à 14:19, Junio C Hamano a écrit :\n>> \n>> \"Julia Evans\" writes:\n>> \n>>> Thanks, I meant to flag this: the reason I deleted it was really\n>>> just that I couldn't understand what `git log --merge -p ` did\n>>> from the documentation and so I removed it until I could figure it out.\n>> \n>> It looks at the index to figure out which paths we got conflicts on,\n>> and then does \"git log -p \". You can\n>> give a pathspec from the command line to further limit the output.\n>\n> This explanation omits the manual’s “HEAD…” argument\n> that the merge option implies, which is important for\n> understanding the option and my alias ;)\n\nAhh, yes, you're right. HEAD...MERGE_HEAD is the more important\nhalf of what --merge gives us that I failed to mention.\n\nAnd without the symmetric difference traversal it gives,\n--left-right would of course not work, either.\n"},{"id":"553522","messageId":"01f196af-3a6a-40e6-86c9-f8b4ce7bfe47@app.fastmail.com","threadId":"66387","inReplyTo":"20260924233726.GB765100@coredump.intra.peff.net","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-09-28T20:41:54Z","receivedAt":"2026-09-28T20:42:15Z","isPatch":true,"body":"> I think that is giving us a good signal, though. The guide should be\n> mentioned in command-list.txt, so that it is linked from git(1).\n\nThanks, will fix this (and will move the conflict-marker-size change).\n\nShould I be trying to apply my patches to `seen` before submitting them?\n\n- Julia\n"},{"id":"553527","messageId":"cc1af300-d296-49c8-98ae-8b30ef11ada3@app.fastmail.com","threadId":"66387","inReplyTo":"xmqqpky1uu6t.fsf@gitster.g","subject":"Re: [PATCH 5/7] [doc] git-cherry-pick: link to new merge conflicts guide","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-09-28T20:58:31Z","receivedAt":"2026-09-28T20:58:52Z","isPatch":true,"body":"\n> The new document may explain how to resolve conflicts, but are the\n> details removed from here that are specific to the 'cherry-pick'\n> operation also covered there?\n\nI'll update this series to make fewer changes to this page as you\nsuggest to make the diff smaller.\n\n> For example, during a difficult cherry-pick, it is often handy to be\n> able to run 'git show CHERRY_PICK_HEAD', but now users are not told\n> about the pseudo-ref, which seems like a real loss.\n\nI'll put this back for now, but I removed it because I couldn't\nunderstand why CHERRY_PICK_HEAD might be useful, and some of my user research\nshowed that almost nobody uses `CHERRY_PICK_HEAD`. I always appreciate people\ntelling me why these things are actually useful though, and even if very few\npeople use something, maybe more people would use it if it was clear why it's\nuseful :)\n\nMy best guess (based on what you said) is that `CHERRY_PICK_HEAD` is\nonly useful if you're cherry-picking multiple commits at the same time.\nIs the following an accurate explanation?:\n\n> If the conflict happened when cherry picking multiple commits, you can run\n> `git show CHERRY_PICK_HEAD` to see the commit that Git failed to apply.\n\n\n\n> The fact that cleanly auto-resolved contents for paths are recorded\n> in the index may be shared with all other merge-like operations,\n> and it need not be part of the \"how to resolve a conflicted\n> merge-like operation\" recipe, but users need to be assured that this\n> is what happens somewhere in the documentation set. The list\n> removed here served that purpose for this specific command, but it\n> is now gone.\n\nThat makes sense to me. One major benefit of making a\ncentralized page is that each man page explains different aspects\nof the merge conflict process, and we can make sure that anyone\nwho needs to solve a merge conflict is aware of all the aspects. \nI'll think about how to explain that.\n"},{"id":"553529","messageId":"xmqqh5j9kr0y.fsf@gitster.g","threadId":"66387","inReplyTo":"cc1af300-d296-49c8-98ae-8b30ef11ada3@app.fastmail.com","subject":"Re: [PATCH 5/7] [doc] git-cherry-pick: link to new merge conflicts guide","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-28T21:25:01Z","receivedAt":"2026-09-28T21:25:06Z","isPatch":true,"body":"\"Julia Evans\" writes:\n\n> My best guess (based on what you said) is that `CHERRY_PICK_HEAD` is\n> only useful if you're cherry-picking multiple commits at the same time.\n> Is the following an accurate explanation?:\n>\n>> If the conflict happened when cherry picking multiple commits, you can run\n>> `git show CHERRY_PICK_HEAD` to see the commit that Git failed to apply.\n\nYou do not have to limit yourself to the multi-pick case. If you\nmake it a habit to use CHERRY_PICK_HEAD, you do not have to remember\nexactly which commit you specified on the command line to pick when\nstopped by a conflict during a cherry-pick. This is especially true\nfor those who have already made it a habit to use MERGE_HEAD when\nstopped by a conflict during a merge. Not having to think when you\ncan mechanically perform a routine task is bliss.\n\n"},{"id":"553533","messageId":"20260929013233.GA1089022@coredump.intra.peff.net","threadId":"66387","inReplyTo":"01f196af-3a6a-40e6-86c9-f8b4ce7bfe47@app.fastmail.com","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-09-29T01:32:33Z","receivedAt":"2026-09-29T01:32:35Z","isPatch":true,"body":"On Mon, Sep 28, 2026 at 04:41:54PM -0400, Julia Evans wrote:\n\n> > I think that is giving us a good signal, though. The guide should be\n> > mentioned in command-list.txt, so that it is linked from git(1).\n> \n> Thanks, will fix this (and will move the conflict-marker-size change).\n> \n> Should I be trying to apply my patches to `seen` before submitting them?\n\nIn general, no, you don't have to. In this case it turned up useful\ninformation for changing your series, but that's rare. The more likely\noutcome is that there's nothing to be changed in your series, but\nthere's a conflict (either textual or semantic) between two topics that\nhas to be resolved by the maintainer.\n\nOf course if you know about that conflict and can warn people in the\ncover letter (and sometimes even suggest a resolution, or work around it\nsomehow), that can distribute some of the load. But I don't know that I\nwould recommend for everyone to manually merge their topic to 'seen' in\nthe hopes that it finds something useful. It usually won't.\n\nBut depending on the rest of your workflow, you might get advanced\nwarning of such interactions for free-ish. For example, I merge all of\nmy personal topics every day to the \"jch\" branch to build the version of\nGit that I run day-to-day. So I learn about those interactions early\nwhen my build fails, or my personal copy breaks. ;) But that's not\nsomething I'd expect most people to do.\n\nIf you do want to look ahead, I think \"next\" or \"jch\" is often a more\nuseful target. A topic on the seen branch just means it was seen by the\nmaintainer, and might not even pass all of the tests. Whereas \"next\" is\nfairly stable, and \"jch\" is (I believe) what Junio runs day to day (so a\nsubset of \"seen\" that seems pretty stable).\n\n-Peff\n"},{"id":"553535","messageId":"xmqqse2skegz.fsf@gitster.g","threadId":"66387","inReplyTo":"20260929013233.GA1089022@coredump.intra.peff.net","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-29T01:56:12Z","receivedAt":"2026-09-29T01:56:15Z","isPatch":true,"body":"Jeff King writes:\n\n> On Mon, Sep 28, 2026 at 04:41:54PM -0400, Julia Evans wrote:\n>\n>> > I think that is giving us a good signal, though. The guide should be\n>> > mentioned in command-list.txt, so that it is linked from git(1).\n>> \n>> Thanks, will fix this (and will move the conflict-marker-size change).\n>> \n>> Should I be trying to apply my patches to `seen` before submitting them?\n>\n> In general, no, you don't have to. In this case it turned up useful\n> ...\n> If you do want to look ahead, I think \"next\" or \"jch\" is often a more\n> useful target.\n\nAs Julia is working mostly on documentation modernization, what you\nand I view as an advantage may not be as relevant to her as it is to\nthose who work with code.\n\nRegardless of which \"more advanced\" branch you pick to cross-check\nwith other topics in flight, I do not think you want to apply your\npatches _on_ that branch. Rather, apply your patches on a stable\nbase (e.g., a release tag, or the tip of then-current 'master'), and\nmake a trial merge of your topic branch into the \"more advanced\"\ntarget branch.\n\nEven without building, you may find merge conflicts, through which\nyou will learn what other contributors are working on in the same\narea. You may run git log --merge --left-right -p right there while\nyou have conflicts, and may even learn that a helper function or two\nyour topic would benefit from have already been written in their\ntopics. Even when there is no textual conflict, 'make' (just\nbuilding alone) may reveal that an API function your topic depends\non has been updated by another topic in flight, and the result does\nnot even build as a consequence. Again, you learn about the topics\nby others that may be very relevant to you.\n\nIf you are working in a fairly isolated area, none of the above may\nhappen, of course.\n\n> A topic on the seen branch just means it was seen by the\n> maintainer, and might not even pass all of the tests. Whereas \"next\" is\n> fairly stable, and \"jch\" is (I believe) what Junio runs day to day (so a\n> subset of \"seen\" that seems pretty stable).\n\nThese days my personal rule is to make sure that the topics must be\nin 'jch' before it is marked with \"Will merge to 'next'\".\n"},{"id":"553695","messageId":"ar0MVRV5X8zgZfLy@pks.im","threadId":"66387","inReplyTo":"ad4853dc36cdb883c9a8dc6bda747a5ea318e7a8.1790261062.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-09-30T13:19:17Z","receivedAt":"2026-09-30T13:19:30Z","isPatch":true,"body":"On Thu, Sep 24, 2026 at 02:44:16PM +0000, Julia Evans via GitGitGadget wrote:\n> diff --git a/Documentation/gitmergeconflicts.adoc b/Documentation/gitmergeconflicts.adoc\n> new file mode 100644\n> index 0000000000..612b683e40\n> --- /dev/null\n> +++ b/Documentation/gitmergeconflicts.adoc\n> @@ -0,0 +1,294 @@\n> +gitmergeconflicts(7)\n> +====================\n> +\n> +NAME\n> +----\n> +gitmergeconflicts - Guide to handling merge conflicts\n> +\n> +\n> +SYNOPSIS\n> +--------\n> +Guide to handling merge conflicts\n> +\n> +\n> +DESCRIPTION\n> +-----------\n> +\n> +Merge conflicts can happen during a `git merge`, `git rebase`, `git\n> +cherry-pick`, `git pull`, or `git revert`. All of those commands use\n\nShould all of these be using linkgit:, like for example in\nlinkgit:git-merge[1]?\n\n> +the same merge algorithm, and the process for resolving a merge conflict\n> +is always very similar.\n\nThere's also git-am(1), but only when adding the \"--3way\" flag. So maybe\nit's best to ignore that command indeed.\n\n> +The most common ways to handle a merge conflict are:\n> +\n> +* Resolve the conflict. (see <>\n> + below for details)\n> +* Or stop the operation and return your branch to its original state\n> + with the appropriate `--abort` command, for example `git merge --abort`\n> + or `git rebase --abort`. See <> below\n> + for how to find the command to run.\n\nI wonder whether the explanation should be expanded a bit to briefly\nexplain how Git performs a 3-way merge in the first place. I feel like\nit's quite important to understand what the three different sides of the\nmerge are to make sense of it.\n\nBut I may be too far detached from the \"normal\" user, so this may only\ncause more confusion for our users.\n\n> +[[markers]]\n> +MERGE CONFLICT MARKERS\n> +----------------------\n> +\n> +Merge conflicts happen when both of the sides being merged edit the same\n> +area of a file. When this happens, Git will update the conflicted file\n\nI wonder whether we want to use \"hunk\" instead of \"area\". It's jargon\nagain, but I have never heard anybody speak about an \"area\" before\nmyself.\n\n> +to include merge conflict markers `<<<<<<<`, `=======`, and `>>>>>>>`.\n> +For example, here's a merge conflict where both sides edited a list of\n> +fruits in different ways:\n> +\n> +----\n> +FRUITS = [\n> + \"apple\",\n> +<<<<<<< HEAD\n> + \"cherry\",\n> +=======\n> + \"banana\",\n> +>>>>>>> add-fruit\n\nA bit of a tangent, but sometimes I wonder whether we should make the\nrespective commits a bit easier to access. For example, we could put the\nequivalent of `git rev-parse --reference ` here for each of the\nsides.\n\n> + \"mango\",\n> + \"orange\",\n> +]\n> +----\n> +\n> +The code from one side of the merge conflict is between `<<<<<<<` and\n> +`=======`, and the code for the other side is between `=======` and\n> +`>>>>>>>`. See <> below for a full explanation\n> +of which side is which.\n> +\n> +\n> +[[resolve]]\n> +HOW TO RESOLVE A MERGE CONFLICT\n> +-------------------------------\n> +\n> +The process for resolving a merge conflict is:\n> +\n> +1. Run `git status` to get a list of files with merge conflicts\n> +2. For each one, find the conflict markers\n> + (the `<<<<<<<`, `=======`, `>>>>>>>`) and edit the code to\n> + fix the conflict\n> +3. Run `git add FILENAME` for each file to mark the conflict as resolved\n> +4. Run the appropriate `--continue` command to continue the operation\n> + that was interrupted by the conflict, for example `git merge --continue`\n> + or `git rebase --continue`. See <>\n> + below for how to find the command to run.\n> ++\n> +Note: During a `git merge`, `git commit` and `git merge --continue` do\n> +the the same thing.\n\ns/the the/the/\n\nMaybe we should also say \"During a conflicted `git merge`.\", but maybe\nthat's redundant.\n\n> +[[example]]\n> +EXAMPLE OF RESOLVING A MERGE CONFLICT\n> +-------------------------------------\n> +\n> +If you see this in your code during a merge conflict:\n> +\n> +----\n> +FRUITS = [\n> + \"apple\",\n> +<<<<<<< HEAD\n> + \"cherry\",\n> + \"mango\",\n> +=======\n> + \"banana\",\n> + \"mango\",\n> +>>>>>>> add-fruit\n> + \"orange\",\n> +]\n> +----\n> +\n> +Then you might edit that part of the code like this,\n> +which includes the fruits from both sides of the conflict:\n\nI tend to forget that by default, we only render ours/theirs in the\nconflict. I always feel like that makes it way harder to resolve\nconflicts as you don't have the context of what the code looked like\noriginally. So I have diff3 configured locally for ages.\n\n> +----\n> +FRUITS = [\n> + \"apple\",\n> + \"banana\",\n> + \"cherry\",\n> + \"mango\",\n> + \"orange\",\n> +]\n> +----\n> +\n> +\n> +[[tools]]\n> +TOOLS FOR HANDLING MERGE CONFLICTS\n> +----------------------------------\n> +\n> +Here are some ways to get extra context while handling a merge conflict:\n> +\n> +* There are many graphical \"merge tools\" for Git, which will normally\n> + show you the different versions of the code side by side.\n> + If you have a mergetool configured, `git mergetool` will launch it.\n> + See also `merge.tool` in linkgit:git-config[1] for a list of\n> + the mergetools Git supports.\n\nThere's also `git merge-tool --tool-help` to list all available drivers.\n\n[snip]\n> +[[diff3]]\n> +DIFF3 AND ZDIFF3\n> +----------------\n> +\n> +By default, Git doesn't include the original code when formatting\n> +a merge conflict. To include the original code, you can set the\n> +configuration option `merge.conflictstyle` to `diff3` or `zdiff3`.\n> +This extra context can make it much easier to understand what's\n> +happening in a merge conflict.\n\nIndeed.\n\n[snip]\n> +[[ours]]\n> +\"OURS\" AND \"THEIRS\"\n> +-------------------\n> +\n> +Git refers to the first part of a merge conflict (between `<<<<<<<`\n> +and `=======`) as \"ours\" and the second part (between `=======` and\n> +`>>>>>>>`) as \"theirs\".\n> +\n> +Normally, \"ours\" is the commit that was checked out before you started\n> +the merge, and \"theirs\" is the other commit.\n> +\n> +But when the merge conflict was caused by a `git rebase`, it's the\n> +opposite: \"theirs\" is the commit that was checked out before you started\n> +the merge. This is because under the hood, `git rebase main` checks out\n> +the `main` commit first before doing the merge operation.\n\nHmm. This part is a bit confusing to me. \"ours\" is always the commit\nthat's currently checked out, and \"theirs\" is always the one that is\ngetting merged into the checked-out commit.\n\nHow about a variant of the following instead?\n\n In a conflict, the side between `<<<<<<<` and `=======` is \"ours\"\n and the side between `=======` and `>>>>>>>` is \"theirs\". \"Ours\" is\n always the side that `HEAD` points to while the merge happens; \"theirs\"\n is the commit being merged into it.\n\n For `git merge `, `HEAD` is your current branch, so \"ours\" is\n your branch and \"theirs\" is ``.\n\n For `git rebase `, `HEAD` is first moved to `` and\n your commits are then replayed on top one at a time. So \"ours\" is the\n already-rebased history starting at ``, and \"theirs\" is the\n commit from your original branch that is currently being replayed.\n\n> +These terms in Git all mean the same thing when dealing with a merge\n> +conflict:\n> +\n> +* \"common ancestor\", \"base\", and \"stage 1\"\n> +* \"ours\", \"us\", \"stage 2\", and `HEAD`\n> +* \"theirs\", \"them\", and \"stage 3\"\n\nI wouldn't say that \"stage N\" is equivalent to the respective other\nterms. These stages rather refer to the different versions of a specific\nfile as recorded in the index, they do not indicate a specific commit.\nIn contrast to that, all the other terms may also indicate a specific\nversion of a file, but may also refer to the commits.\n\nPatrick\n"},{"id":"553696","messageId":"ar0MZkCygtK4Qa31@pks.im","threadId":"66387","inReplyTo":"a1686a2d82ef9357ecff07c1247092d3dd5ecf95.1790261062.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-09-30T13:19:34Z","receivedAt":"2026-09-30T13:19:43Z","isPatch":true,"body":"On Thu, Sep 24, 2026 at 02:44:17PM +0000, Julia Evans via GitGitGadget wrote:\n> From: Julia Evans \n> \n> All of the info about merge conflicts has been moved to the new guide\n\nPedantic nit: missing punctuation.\n\nOther than that I agree with Ben, one part that we lose here is some\ncontext on what a merge conflict even is.\n\nPatrick\n"},{"id":"553747","messageId":"5ba2088c-4919-465f-8892-4ed0685f81ea@app.fastmail.com","threadId":"66387","inReplyTo":"ar0MVRV5X8zgZfLy@pks.im","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-09-30T19:53:17Z","receivedAt":"2026-09-30T19:53:38Z","isPatch":true,"body":">> +Merge conflicts can happen during a `git merge`, `git rebase`, `git\n>> +cherry-pick`, `git pull`, or `git revert`. All of those commands use\n>\n> Should all of these be using linkgit:, like for example in\n> linkgit:git-merge[1]?\n\nMakes sense to me, will change.\n\n>> +The most common ways to handle a merge conflict are:\n>> +\n>> +* Resolve the conflict. (see <>\n>> + below for details)\n>> +* Or stop the operation and return your branch to its original state\n>> + with the appropriate `--abort` command, for example `git merge --abort`\n>> + or `git rebase --abort`. See <> below\n>> + for how to find the command to run.\n>\n> I wonder whether the explanation should be expanded a bit to briefly\n> explain how Git performs a 3-way merge in the first place. I feel like\n> it's quite important to understand what the three different sides of the\n> merge are to make sense of it.\n>\n> But I may be too far detached from the \"normal\" user, so this may only\n> cause more confusion for our users.\n\nI think it would cause more confusion. I did some experiments in explaining\nmerge conflicts using the concept of 3-way merge a couple of years\nago and it didn't go well.\n\nMy experience was that what users they found the most useful was\nlearning about the tools Git offers (like `git diff --check` and `diff3`),\nso that's why this document focuses on tools and formatting much\nmore than concepts.\n\nI think it would be cool to find a way to explain how 3-way merge works at in\nthis document in some later iteration though, maybe at the end. Definitely some\nfolks would find it interesting. I didn't understand 3-way merge myself until a\ncouple of years ago and it was fun for me to learn, but it didn't really help me\nuse Git effectively.\n\n(this is quickly becoming a bit of a novel, but it's often very counterintuitive\nhow some facts that seem \"fundamental\" about how Git works actually turn\nout to not be very important to understand in practice to use it effectively.\nIt's something I find tough to talk about on this mailing list because it's something\nI've only been able to learn empirically)\n\n>> +[[markers]]\n>> +MERGE CONFLICT MARKERS\n>> +----------------------\n>> +\n>> +Merge conflicts happen when both of the sides being merged edit the same\n>> +area of a file. When this happens, Git will update the conflicted file\n>\n> I wonder whether we want to use \"hunk\" instead of \"area\". It's jargon\n> again, but I have never heard anybody speak about an \"area\" before\n> myself.\n\nAh thanks, I think I took \"area\" from the `git-merge` man page.\n\nI looked up how I explained this previously and I used \"lines of code\",\nwhich I think communicates the same meaning without the jargon.\nI'll try that instead.\n\n>> +Note: During a `git merge`, `git commit` and `git merge --continue` do\n>> +the the same thing.\n>\n> s/the the/the/\n\nWill fix. \n\n>> +to include merge conflict markers `<<<<<<<`, `=======`, and `>>>>>>>`.\n>> +For example, here's a merge conflict where both sides edited a list of\n>> +fruits in different ways:\n>> +\n>> +----\n>> +FRUITS = [\n>> + \"apple\",\n>> +<<<<<<< HEAD\n>> + \"cherry\",\n>> +=======\n>> + \"banana\",\n>> +>>>>>>> add-fruit\n> Hide quoted text\n>\n> A bit of a tangent, but sometimes I wonder whether we should make the\n> respective commits a bit easier to access. For example, we could put the\n> equivalent of `git rev-parse --reference ` here for each of the\n> sides.\n\nPersonally I'm not sure if the commit ID would do much for me, but I feel\nlike it would help me if it were possible to include the commit message. \n\n> I tend to forget that by default, we only render ours/theirs in the\n> conflict. I always feel like that makes it way harder to resolve\n> conflicts as you don't have the context of what the code looked like\n> originally. So I have diff3 configured locally for ages.\n\nEvery time I show people diff3 someone tells me how happy they\nare to learn it :)\n\n>> +* There are many graphical \"merge tools\" for Git, which will normally\n>> + show you the different versions of the code side by side.\n>> + If you have a mergetool configured, `git mergetool` will launch it.\n>> + See also `merge.tool` in linkgit:git-config[1] for a list of\n>> + the mergetools Git supports.\n>\n> There's also `git merge-tool --tool-help` to list all available drivers.\n\nOh, cool! It's fun that it autodetects which ones you have installed\non your system. I'll suggest that.\n\n>\n> [snip]\n>> +[[ours]]\n>> +\"OURS\" AND \"THEIRS\"\n>> +-------------------\n>> +\n>> +Git refers to the first part of a merge conflict (between `<<<<<<<`\n>> +and `=======`) as \"ours\" and the second part (between `=======` and\n>> +`>>>>>>>`) as \"theirs\".\n>> +\n>> +Normally, \"ours\" is the commit that was checked out before you started\n>> +the merge, and \"theirs\" is the other commit.\n>> +\n>> +But when the merge conflict was caused by a `git rebase`, it's the\n>> +opposite: \"theirs\" is the commit that was checked out before you started\n>> +the merge. This is because under the hood, `git rebase main` checks out\n>> +the `main` commit first before doing the merge operation.\n>\n> Hmm. This part is a bit confusing to me. \"ours\" is always the commit\n> that's currently checked out, and \"theirs\" is always the one that is\n> getting merged into the checked-out commit.\n>\n> How about a variant of the following instead?\n>\n> In a conflict, the side between `<<<<<<<` and `=======` is \"ours\"\n> and the side between `=======` and `>>>>>>>` is \"theirs\". \"Ours\" is\n> always the side that `HEAD` points to while the merge happens; \"theirs\"\n> is the commit being merged into it.\n>\n> For `git merge `, `HEAD` is your current branch, so \"ours\" is\n> your branch and \"theirs\" is ``.\n>\n> For `git rebase `, `HEAD` is first moved to `` and\n> your commits are then replayed on top one at a time. So \"ours\" is the\n> already-rebased history starting at ``, and \"theirs\" is the\n> commit from your original branch that is currently being replayed.\n\nThanks, your suggestion gives me some other ways to think about this.\n\nI think I'll try to write something shorter that is unambiguous, instead of trying\nto use more words to make it feel more intuitive. I don't think I actually know\nanyone who feels it's easy to understand the way merge conflicts are\npresented, and more explanation may not help.\n\nIt might be more useful here to encourage (again) folks to use one of the many\namazing tools available (in the \"tools\" section) to get more context.\n\n>> +These terms in Git all mean the same thing when dealing with a merge\n>> +conflict:\n>> +\n>> +* \"common ancestor\", \"base\", and \"stage 1\"\n>> +* \"ours\", \"us\", \"stage 2\", and `HEAD`\n>> +* \"theirs\", \"them\", and \"stage 3\"\n>\n> I wouldn't say that \"stage N\" is equivalent to the respective other\n> terms. These stages rather refer to the different versions of a specific\n> file as recorded in the index, they do not indicate a specific commit.\n> In contrast to that, all the other terms may also indicate a specific\n> version of a file, but may also refer to the commits.\n\nThanks, will try to figure out how to make it more accurate.\nWe could also refer to gitdatamodel if folks want to learn what the\nterm \"stage\" means too.\n\nThanks for the review!\n- Julia\n"},{"id":"553755","messageId":"xmqqqzia8ohv.fsf@gitster.g","threadId":"66387","inReplyTo":"5ba2088c-4919-465f-8892-4ed0685f81ea@app.fastmail.com","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-30T20:37:16Z","receivedAt":"2026-09-30T20:37:18Z","isPatch":true,"body":"\"Julia Evans\" writes:\n\n>>> +to include merge conflict markers `<<<<<<<`, `=======`, and `>>>>>>>`.\n>>> +For example, here's a merge conflict where both sides edited a list of\n>>> +fruits in different ways:\n>>> +\n>>> +----\n>>> +FRUITS = [\n>>> + \"apple\",\n>>> +<<<<<<< HEAD\n>>> + \"cherry\",\n>>> +=======\n>>> + \"banana\",\n>>> +>>>>>>> add-fruit\n>> Hide quoted text\n>>\n>> A bit of a tangent, but sometimes I wonder whether we should make the\n>> respective commits a bit easier to access. For example, we could put the\n>> equivalent of `git rev-parse --reference ` here for each of the\n>> sides.\n>\n> Personally I'm not sure if the commit ID would do much for me, but I feel\n> like it would help me if it were possible to include the commit message. \n\nIt would also help the resolution, not just committing after you are\ndone. It may not matter while picking between cherry and banana to\nshow your personal preference on fruits, but in a more involved\nconflicted merge, it may help to be able to view \"git show $commit\",\n\"git diff ...$commit\", and \"git diff $commit...\" where $commit is\nthe \"add-fruit\" side of the merge to understand what they wanted to\ndo, and what we have done while they weren't looking.\n\n>> I tend to forget that by default, we only render ours/theirs in the\n>> conflict. I always feel like that makes it way harder to resolve\n>> conflicts as you don't have the context of what the code looked like\n>> originally. So I have diff3 configured locally for ages.\n>\n> Every time I show people diff3 someone tells me how happy they\n> are to learn it :)\n\nYes, we should encourage \"merge.conflictstyle=diff3\" (I feel about\nthis strongly enough to think it should become the default).\nKnowing what the original was before one side wanted to say \"cherry\"\nwhile the other side wanted to say \"banana\" sometimes helps a great\ndeal to decide what to do with the conflict.\n"},{"id":"553804","messageId":"ar3sGzEknG2_Un_E@pks.im","threadId":"66387","inReplyTo":"xmqqqzia8ohv.fsf@gitster.g","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-10-01T05:14:03Z","receivedAt":"2026-10-01T05:14:10Z","isPatch":true,"body":"On Wed, Sep 30, 2026 at 01:37:16PM -0700, Junio C Hamano wrote:\n> \"Julia Evans\" writes:\n> \n> >>> +to include merge conflict markers `<<<<<<<`, `=======`, and `>>>>>>>`.\n> >>> +For example, here's a merge conflict where both sides edited a list of\n> >>> +fruits in different ways:\n> >>> +\n> >>> +----\n> >>> +FRUITS = [\n> >>> + \"apple\",\n> >>> +<<<<<<< HEAD\n> >>> + \"cherry\",\n> >>> +=======\n> >>> + \"banana\",\n> >>> +>>>>>>> add-fruit\n> >> Hide quoted text\n> >>\n> >> A bit of a tangent, but sometimes I wonder whether we should make the\n> >> respective commits a bit easier to access. For example, we could put the\n> >> equivalent of `git rev-parse --reference ` here for each of the\n> >> sides.\n> >\n> > Personally I'm not sure if the commit ID would do much for me, but I feel\n> > like it would help me if it were possible to include the commit message. \n> \n> It would also help the resolution, not just committing after you are\n> done. It may not matter while picking between cherry and banana to\n> show your personal preference on fruits, but in a more involved\n> conflicted merge, it may help to be able to view \"git show $commit\",\n> \"git diff ...$commit\", and \"git diff $commit...\" where $commit is\n> the \"add-fruit\" side of the merge to understand what they wanted to\n> do, and what we have done while they weren't looking.\n\nYup. Doesn't mean we cannot _also_ include the names that we have above.\nSo in the above example it could be for example:\n\n+FRUITS = [\n+ \"apple\",\n+<<<<<<< HEAD: abcdefg (fruits: add apple, 2026-10-01)\n+ \"cherry\",\n+=======\n+ \"banana\",\n+>>>>>>> add-fruit: 12345678 (fruits: add banana, 2024-02-03)\n\nThat format would have a bunch of advantages:\n\n - We don't have to teach users about special refs like MERGE_HEAD to\n let them figure out how to access each of the commits.\n\n - It gives a bit more context about what each specific side does, at\n least if you have good commit messages.\n\n - It also gives a sense of timing because we include dates, and that\n may help in some situations to figure out what's what.\n\nI'll create an issue on the GitLab side and ask someone in the team to\nmaybe give this a try.\n\n> >> I tend to forget that by default, we only render ours/theirs in the\n> >> conflict. I always feel like that makes it way harder to resolve\n> >> conflicts as you don't have the context of what the code looked like\n> >> originally. So I have diff3 configured locally for ages.\n> >\n> > Every time I show people diff3 someone tells me how happy they\n> > are to learn it :)\n> \n> Yes, we should encourage \"merge.conflictstyle=diff3\" (I feel about\n> this strongly enough to think it should become the default).\n> Knowing what the original was before one side wanted to say \"cherry\"\n> while the other side wanted to say \"banana\" sometimes helps a great\n> deal to decide what to do with the conflict.\n\nI very much agree that it should be the default.\n\nPatrick\n"},{"id":"553833","messageId":"86a7df9d-362a-4530-82db-44ef7500fd10@app.fastmail.com","threadId":"66387","inReplyTo":"ar3sGzEknG2_Un_E@pks.im","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-10-01T12:10:11Z","receivedAt":"2026-10-01T12:10:37Z","isPatch":true,"body":"\n> +FRUITS = [\n> + \"apple\",\n> +<<<<<<< HEAD: abcdefg (fruits: add apple, 2026-10-01)\n> + \"cherry\",\n> +=======\n> + \"banana\",\n> +>>>>>>> add-fruit: 12345678 (fruits: add banana, 2024-02-03)\n>\n> That format would have a bunch of advantages:\n>\n> - We don't have to teach users about special refs like MERGE_HEAD to\n> let them figure out how to access each of the commits.\n>\n> - It gives a bit more context about what each specific side does, at\n> least if you have good commit messages.\n>\n> - It also gives a sense of timing because we include dates, and that\n> may help in some situations to figure out what's what.\n\nThis is so cool, I love the idea of including the dates and the commit\nmessages!!! I think this would be very helpful for the reasons you say. \n\nThough re \"We don't have to teach users about special refs\nlike MERGE_HEAD\": I think that users today could run`git show HEAD`\nor `git show add-fruit` to see the commits on each side? I've never\nused MERGE_HEAD though so maybe I'm misunderstanding what\nit does. I think adding the commit ID makes it clearer too.\n\nI just ran downstairs to show my partner this example at 8am\nbecause I was so excited about it :) (he liked it too)\n"},{"id":"553985","messageId":"4e579181-e93a-4746-8c2d-b127cb0e053d@app.fastmail.com","threadId":"66387","inReplyTo":"2f71028f-d58e-400f-a02e-7a25c032d889@app.fastmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-10-02T17:01:20Z","receivedAt":"2026-10-02T17:01:41Z","isPatch":true,"body":"\n\nOn Fri, Sep 25, 2026, at 12:59 PM, Julia Evans wrote:\n> On Fri, Sep 25, 2026, at 12:36 PM, D. Ben Knoble wrote:\n>> Hi Julia,\n>>\n>> On Thu, Sep 24, 2026 at 10:46 AM Julia Evans via GitGitGadget\n>> wrote:\n>>>\n>>> From: Julia Evans \n>>>\n>>> All of the info about merge conflicts has been moved to the new guide\n>>\n>>> Among the changes made to the common ancestor's version,\n>>> -non-overlapping ones (that is, you changed an area of the file while the\n>>> -other side left that area intact, or vice versa) are incorporated in the\n>>> -final result verbatim. When both sides made changes to the same area,\n>>> -however, Git cannot randomly pick one side over the other, and asks you to\n>>> -resolve it by leaving what both sides did to that area.\n\n>> I think these are both valuable pieces of information we have lost in\n>> the new guide (unless I misremember just having read patch 1 :).\n>>\n>> The first explains a bit more about what a conflict *is*. Maybe that's\n>> old-hat nowadays, but I think it could be nice to keep a statement\n>> about why conflicts exist.\n>\n> Will think about this!\n\nAfter talking this through with my collaborator Marie, we wrote a new\n\"what is a merge conflict?\" section which I'll include in the v2.\n\nLike I mentioned before elsewhere it takes a super light approach to\nintroducing the 3-way merge. (there is intentionally no mention\nof \"since they diverged from the common ancestor\" etc)\n\n WHAT IS A MERGE CONFLICT?\n -------------------------\n\n When Git merges two commits together, it looks at the changes that\n each side has made and combines those changes. For example, if one side\n edited lines 1-5 of `hello.py` and the other side edited lines 20-25 of\n `hello.py`, then it can easily combine them.\n\n But if both sides edited overlapping lines of the same file (for example\n one side edited lines 1-5 and the other edited lines 3-6), Git will\n not try to guess how to combine those changes. This is called a \"merge\n conflict\".\n\n When this happens, Git shows you both sides' edits and asks you to pick\n how to resolve them. It:\n\n * Stages all of the files which were successfully merged\n * For the files with conflicts, it leaves them unstaged, puts both\n sides' edits in the file, and leaves <>\n that you need to resolve.\n"},{"id":"553990","messageId":"91396552-f86b-47d7-9805-8f6056c2ed66@app.fastmail.com","threadId":"66387","inReplyTo":"CALnO6CA_=OsznkQ4iT0vBMWf3L=bmVKMBdk1MTHQdaKEcKwn4g@mail.gmail.com","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-10-02T17:39:44Z","receivedAt":"2026-10-02T17:40:08Z","isPatch":true,"body":"Thanks for the review!\n\n>> * I wrote that git commit does the same thing as git merge --continue\n>> during a git merge , but I'm not sure if that's always true.\n>\n> See also discussion in\n> https://lore.kernel.org/git/CABPp-BEQSx4m3BcT28CpVGCtsH75+x3gmv4OJz_ecLVLx+kBWg@mail.gmail.com/T/#t\n\nWow, that's a very interesting read. I'm more informed than I was before\nI read it but also at the same time more confused :). It makes me think\nthat \"git commit does the same thing as git merge --continue\" is maybe\nnot true but also I don't know what the difference might be.\n\nI've put an item on my TODO list to remove \n`git commit does the same thing as git merge --continue`\" and to try to\nreplace it with a more vague sentence that I guess says you can use\neither command without being so specific on whether they are exactly\nthe same.\n\n>> Also if/when the git rebase --squash changes land, then we'd need\n>> to add git history to this list.\n>\n> I imagine you meant history squash? I also thought that history had\n> punted on how to deal with conflicts (rejecting any operation which\n> creates them) for now, since we don't have 1st-class conflicts à la\n> Jujutsu.\n\nGood to know! Removed this from my v2 cover letter draft.\n"},{"id":"553993","messageId":"xmqqh5j4vvor.fsf@gitster.g","threadId":"66387","inReplyTo":"4e579181-e93a-4746-8c2d-b127cb0e053d@app.fastmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-02T17:50:12Z","receivedAt":"2026-10-02T17:50:18Z","isPatch":true,"body":"\"Julia Evans\" writes:\n\n> Like I mentioned before elsewhere it takes a super light approach to\n> introducing the 3-way merge. (there is intentionally no mention\n> of \"since they diverged from the common ancestor\" etc)\n>\n> WHAT IS A MERGE CONFLICT?\n> -------------------------\n>\n> When Git merges two commits together, it looks at the changes that\n> each side has made and combines those changes. For example, if one side\n> edited lines 1-5 of `hello.py` and the other side edited lines 20-25 of\n> `hello.py`, then it can easily combine them.\n\nSome immediate reactions.\n\n - Is it obvious that the reason why it can \"easily combine\" them,\n or would it help to be more explicit (i.e., \"as there is no\n overlap\")?\n\n - The second \"of `hello.py`\" forced me to go back and look at the\n first one again to make sure we are talking about the same file.\n I would imagine if the latter were \"lines 20-25 of the same file\",\n it would have read better at least to me.\n\n> But if both sides edited overlapping lines of the same file (for example\n> one side edited lines 1-5 and the other edited lines 3-6), Git will\n> not try to guess how to combine those changes. This is called a \"merge\n> conflict\".\n\n - \"cannot guess\" would be more direct than \"will not try to guess\".\n\n> When this happens, Git shows you both sides' edits and asks you to pick\n> how to resolve them. It:\n>\n> * Stages all of the files which were successfully merged\n\n - \"merged without conflicts\" would be more direct than \"successfully merged\".\n\n> * For the files with conflicts, it leaves them unstaged, puts both\n> sides' edits in the file, and leaves <>\n> that you need to resolve.\n\n - \"unstaged\" sounds as if somebody ran \"git rm --cached\" on the\n paths, but that is not what you want to tell your readers.\n\n - \"it leaves them unstaged\" -> \"it remembers them as conflicted\",\n perhaps? This hints that Git has a mechanism to remember the\n conflicted paths even after you removed the conflict markers from\n the file to your readers.\n\n\n"},{"id":"553994","messageId":"xmqqbj9cvvaa.fsf@gitster.g","threadId":"66387","inReplyTo":"xmqqqzia8ohv.fsf@gitster.g","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-02T17:58:53Z","receivedAt":"2026-10-02T17:58:58Z","isPatch":true,"body":"Junio C Hamano writes:\n\n>>>> +FRUITS = [\n>>>> + \"apple\",\n>>>> +<<<<<<< HEAD\n>>>> + \"cherry\",\n>>>> +=======\n>>>> + \"banana\",\n>>>> +>>>>>>> add-fruit\n>\n>> Every time I show people diff3 someone tells me how happy they\n>> are to learn it :)\n>\n> Yes, we should encourage \"merge.conflictstyle=diff3\" (I feel about\n> this strongly enough to think it should become the default).\n> Knowing what the original was before one side wanted to say \"cherry\"\n> while the other side wanted to say \"banana\" sometimes helps a great\n> deal to decide what to do with the conflict.\n\nBefore I forget, here is a good illustration to tell why diff3 style\nis often essential to correct conflict resolution that we can tell\nnew users. You may want to throw it in to your new manual pages.\n\nIf the conflict looks like this\n\n FRUITS = [ \n \"apple\", \n <<<<<<< HEAD \n \"cherry\", \n\t|||||||\n ======= \n \"banana\", \n >>>>>>> add-fruit\n\nthen we can tell that in the beginning there was only 'apple', and\none side wanted to add 'cherry', while the other side wanted to add\n'banana'. It is likely that we would make both sides happy by\nadding both of them.\n\nBut on the other hand, if the conflict looks like this\n\n FRUITS = [ \n \"apple\", \n <<<<<<< HEAD \n \"cherry\", \n\t|||||||\n\t \"banana\",\n\t \"cherry\",\n ======= \n \"banana\", \n >>>>>>> add-fruit\n\nwe can tell that before two sides started editing, we had 'apple',\n'banana', and 'cherry'. While both wanted to keep 'apple', one side\ndid not want 'banana', and the other side did not want 'cherry'. It\nis plausible that we can please both of them by removing these two.\n\nWith just two-sides, the user who is trying to resolve the conflict\ncannot tell the difference.\n"},{"id":"553999","messageId":"7861e492-6fa4-4768-afdd-65cd346b85be@app.fastmail.com","threadId":"66387","inReplyTo":"xmqqh5j4vvor.fsf@gitster.g","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-10-02T18:53:19Z","receivedAt":"2026-10-02T18:53:40Z","isPatch":true,"body":">> WHAT IS A MERGE CONFLICT?\n>> -------------------------\n>>\n>> When Git merges two commits together, it looks at the changes that\n>> each side has made and combines those changes. For example, if one side\n>> edited lines 1-5 of `hello.py` and the other side edited lines 20-25 of\n>> `hello.py`, then it can easily combine them.\n>\n> Some immediate reactions.\n\nThanks, incorporated a few of these (\"it marks them as conflicted\",\n\"since there's no overlap\", \"the same file\")\n\n>> But if both sides edited overlapping lines of the same file (for example\n>> one side edited lines 1-5 and the other edited lines 3-6), Git will\n>> not try to guess how to combine those changes. This is called a \"merge\n>> conflict\".\n>\n> - \"cannot guess\" would be more direct than \"will not try to guess\".\n\nThe way I think about it as a user is that Git takes an intentionally conservative\napproach and I appreciate the conservatism. Compared to a more aggressive\nsyntax-aware merge system like `mergiraf` which has done merges I don't\nagree with.\n"},{"id":"554013","messageId":"xmqqjynzvl4w.fsf@gitster.g","threadId":"66387","inReplyTo":"7861e492-6fa4-4768-afdd-65cd346b85be@app.fastmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-02T21:38:07Z","receivedAt":"2026-10-02T21:38:10Z","isPatch":true,"body":"\"Julia Evans\" writes:\n\n>> - \"cannot guess\" would be more direct than \"will not try to guess\".\n>\n> The way I think about it as a user is that Git takes an intentionally conservative\n> approach and I appreciate the conservatism. Compared to a more aggressive\n> syntax-aware merge system like `mergiraf` which has done merges I don't\n> agree with.\n\nYour disagreement with their result suggests that they guessed when\nthey could not do so reliably. I agree that our approach is more\nconservative, but we can call it being more honest.\n\n;-).\n"},{"id":"554040","messageId":"CALnO6CDoMTtyPJyOiXVPSZvFGHgGkFT-u_Qk1km+XYn9BR0OHg@mail.gmail.com","threadId":"66387","inReplyTo":"4e579181-e93a-4746-8c2d-b127cb0e053d@app.fastmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-10-03T02:25:13Z","receivedAt":"2026-10-03T02:25:25Z","isPatch":true,"body":"On Fri, Oct 2, 2026 at 1:01 PM Julia Evans wrote:\n>\n>\n>\n> On Fri, Sep 25, 2026, at 12:59 PM, Julia Evans wrote:\n> > On Fri, Sep 25, 2026, at 12:36 PM, D. Ben Knoble wrote:\n> >> Hi Julia,\n> >>\n> >> On Thu, Sep 24, 2026 at 10:46 AM Julia Evans via GitGitGadget\n> >> wrote:\n> >>>\n> >>> From: Julia Evans \n> >>>\n> >>> All of the info about merge conflicts has been moved to the new guide\n> >>\n> >>> Among the changes made to the common ancestor's version,\n> >>> -non-overlapping ones (that is, you changed an area of the file while the\n> >>> -other side left that area intact, or vice versa) are incorporated in the\n> >>> -final result verbatim. When both sides made changes to the same area,\n> >>> -however, Git cannot randomly pick one side over the other, and asks you to\n> >>> -resolve it by leaving what both sides did to that area.\n>\n> >> I think these are both valuable pieces of information we have lost in\n> >> the new guide (unless I misremember just having read patch 1 :).\n> >>\n> >> The first explains a bit more about what a conflict *is*. Maybe that's\n> >> old-hat nowadays, but I think it could be nice to keep a statement\n> >> about why conflicts exist.\n> >\n> > Will think about this!\n>\n> After talking this through with my collaborator Marie, we wrote a new\n> \"what is a merge conflict?\" section which I'll include in the v2.\n>\n> Like I mentioned before elsewhere it takes a super light approach to\n> introducing the 3-way merge. (there is intentionally no mention\n> of \"since they diverged from the common ancestor\" etc)\n>\n> WHAT IS A MERGE CONFLICT?\n> -------------------------\n>\n> When Git merges two commits together, it looks at the changes that\n> each side has made and combines those changes. For example, if one side\n> edited lines 1-5 of `hello.py` and the other side edited lines 20-25 of\n> `hello.py`, then it can easily combine them.\n>\n> But if both sides edited overlapping lines of the same file (for example\n> one side edited lines 1-5 and the other edited lines 3-6), Git will\n> not try to guess how to combine those changes. This is called a \"merge\n> conflict\".\n>\n> When this happens, Git shows you both sides' edits and asks you to pick\n> how to resolve them. It:\n>\n> * Stages all of the files which were successfully merged\n> * For the files with conflicts, it leaves them unstaged, puts both\n> sides' edits in the file, and leaves <>\n> that you need to resolve.\n>\n\nI quite like this. I'm sure it oversimplifies somewhere, but at least\nI personally cannot immediately see where (or how it does any harm to)\n;)\n\nThanks!\n\nPS Unlike Junio---perhaps due to my lack of older Git history and\nterminology, despite using Git since 2016?---I would never have read\n\"unstaged\" as *deleted* from the index. Just changed and not updated\nin the index (i.e., not \"git add\"-ed).\n\n-- \nD. Ben Knoble\n"},{"id":"554041","messageId":"CALnO6CC+h1y=Fu438nm4cd0K-dfPVYq9MqX_+k8fxBU60ot8KA@mail.gmail.com","threadId":"66387","inReplyTo":"91396552-f86b-47d7-9805-8f6056c2ed66@app.fastmail.com","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-10-03T02:29:05Z","receivedAt":"2026-10-03T02:29:17Z","isPatch":true,"body":"On Fri, Oct 2, 2026 at 1:40 PM Julia Evans wrote:\n>\n> Thanks for the review!\n>\n> >> * I wrote that git commit does the same thing as git merge --continue\n> >> during a git merge , but I'm not sure if that's always true.\n> >\n> > See also discussion in\n> > https://lore.kernel.org/git/CABPp-BEQSx4m3BcT28CpVGCtsH75+x3gmv4OJz_ecLVLx+kBWg@mail.gmail.com/T/#t\n>\n> Wow, that's a very interesting read. I'm more informed than I was before\n> I read it but also at the same time more confused :). It makes me think\n> that \"git commit does the same thing as git merge --continue\" is maybe\n> not true but also I don't know what the difference might be.\n>\n> I've put an item on my TODO list to remove\n> `git commit does the same thing as git merge --continue`\" and to try to\n> replace it with a more vague sentence that I guess says you can use\n> either command without being so specific on whether they are exactly\n> the same.\n\nFor now I would say the subtleties in that conversation really make me\nlean towards the following:\n\n- \"git --continue\" is, for most users in most cases, the right\nthing to do. It's what \"git status\" recommends and will practically\nnever do anything surprising (?).\n- However, it may not always be exactly what you *want*---and you'll\nusually know when you want to go \"outside\" the normal sequencer and\ncommit directly (because you'll have understood some nuanced details\nabout what can happen).\n\nFor merge it may be the case that they're the same, I suppose (I'm\ngenuinely not sure), but I would prefer to simplify folks' paths by\nrecommending one of the few uniform interfaces we have :)\n"},{"id":"554042","messageId":"xmqqik3jtob2.fsf@gitster.g","threadId":"66387","inReplyTo":"CALnO6CDoMTtyPJyOiXVPSZvFGHgGkFT-u_Qk1km+XYn9BR0OHg@mail.gmail.com","subject":"Re: [PATCH 2/7] [doc] git-merge: link to new merge conflicts guide","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-03T04:12:33Z","receivedAt":"2026-10-03T04:12:36Z","isPatch":true,"body":"\"D. Ben Knoble\" writes:\n\n> PS Unlike Junio---perhaps due to my lack of older Git history and\n> terminology, despite using Git since 2016?---I would never have read\n> \"unstaged\" as *deleted* from the index. Just changed and not updated\n> in the index (i.e., not \"git add\"-ed).\n\nI agree such an interpretation is certainly possible.\n\nThe verb \"to unstage\" would be the opposite of \"to stage\", but it is\nambiguous what kind of oppositeness you want to express. This is\nunlike \"to stage\" whose possible interpretation is fairly narrow.\nYou register the contents that you consider desirable for the path\nusing various means. On the other hand, \"to unstage\" is undoing the\nresult of your earlier act \"to stage\", but it may mean reverting to\nwhat is recorded in HEAD (i.e., \"git reset HEAD -- path\"), undoing\nthe fact that you added a path to the index (i.e., \"git rm --cached\n-- path\"). Neither interpretation is what you want when talking\nabout what a conflicted merge does to remember the three stages for\na conflicted path in the index.\n\nHence my suggestion to avoid using the verb.\n\n"},{"id":"554202","messageId":"e593f3ca-4a03-45a7-b0cc-6295a3a4939f@app.fastmail.com","threadId":"66387","inReplyTo":"5ba2088c-4919-465f-8892-4ed0685f81ea@app.fastmail.com","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-10-05T16:54:03Z","receivedAt":"2026-10-05T16:54:03Z","isPatch":true,"body":"\n>> [snip]\n>>> +[[ours]]\n>>> +\"OURS\" AND \"THEIRS\"\n>>> +-------------------\n>>> +\n>>> +Git refers to the first part of a merge conflict (between `<<<<<<<`\n>>> +and `=======`) as \"ours\" and the second part (between `=======` and\n>>> +`>>>>>>>`) as \"theirs\".\n>>> +\n>>> +Normally, \"ours\" is the commit that was checked out before you started\n>>> +the merge, and \"theirs\" is the other commit.\n>>> +\n>>> +But when the merge conflict was caused by a `git rebase`, it's the\n>>> +opposite: \"theirs\" is the commit that was checked out before you started\n>>> +the merge. This is because under the hood, `git rebase main` checks out\n>>> +the `main` commit first before doing the merge operation.\n>>\n>> Hmm. This part is a bit confusing to me. \"ours\" is always the commit\n>> that's currently checked out, and \"theirs\" is always the one that is\n>> getting merged into the checked-out commit.\n>>\n>> How about a variant of the following instead?\n>>\n>> In a conflict, the side between `<<<<<<<` and `=======` is \"ours\"\n>> and the side between `=======` and `>>>>>>>` is \"theirs\". \"Ours\" is\n>> always the side that `HEAD` points to while the merge happens; \"theirs\"\n>> is the commit being merged into it.\n>>\n>> For `git merge `, `HEAD` is your current branch, so \"ours\" is\n>> your branch and \"theirs\" is ``.\n>>\n>> For `git rebase `, `HEAD` is first moved to `` and\n>> your commits are then replayed on top one at a time. So \"ours\" is the\n>> already-rebased history starting at ``, and \"theirs\" is the\n>> commit from your original branch that is currently being replayed.\n>\n> Thanks, your suggestion gives me some other ways to think about this.\n>\n> I think I'll try to write something shorter that is unambiguous, \n> instead of trying\n> to use more words to make it feel more intuitive. I don't think I \n> actually know\n> anyone who feels it's easy to understand the way merge conflicts are\n> presented, and more explanation may not help.\n>\n> It might be more useful here to encourage (again) folks to use one of the many\n> amazing tools available (in the \"tools\" section) to get more context.\n>\n>>> +These terms in Git all mean the same thing when dealing with a merge\n>>> +conflict:\n>>> +\n>>> +* \"common ancestor\", \"base\", and \"stage 1\"\n>>> +* \"ours\", \"us\", \"stage 2\", and `HEAD`\n>>> +* \"theirs\", \"them\", and \"stage 3\"\n>>\n>> I wouldn't say that \"stage N\" is equivalent to the respective other\n>> terms. These stages rather refer to the different versions of a specific\n>> file as recorded in the index, they do not indicate a specific commit.\n>> In contrast to that, all the other terms may also indicate a specific\n>> version of a file, but may also refer to the commits.\n>\n> Thanks, will try to figure out how to make it more accurate.\n> We could also refer to gitdatamodel if folks want to learn what the\n> term \"stage\" means too.\n\nMarie and I worked on the OURS AND THEIRS section today and I think it's clearer\nnow but also longer (instead of shorter which was my dream). We added an attempt\nat humor at the end to hopefully help things a bit.\n\n\t\"OURS\" AND \"THEIRS\"\n\t-------------------\n\n\tSometimes during a merge conflict, Git will use the terms \"ours\" and\n\t\"theirs\" (or \"us\" and \"them\"). For example, `git status` might say that\n\ta file was `deleted by us`.\n\n\t\"Ours\" and \"theirs\" are both commits: \"ours\" is the current\n\t`HEAD` commit, and \"theirs\" is the other side being merged.\n\n\tThe first part of a merge conflict (between `<<<<<<<` and `=======`) is\n\tfrom the \"ours\" side, and the second part (between `=======` and\n\t`>>>>>>>`) is from the \"theirs\" side.\n\n\t----\n\tFRUITS = [\n\t \"apple\",\n\t<<<<<<< HEAD\n\t \"cherry\", <- ours\n\t=======\n\t \"banana\", <- theirs\n\t>>>>>>> add-fruit\n\t \"mango\",\n\t \"orange\",\n\t]\n\t----\n\n\tDuring a rebase, it can seem \"upside down\" because the \"ours\" commit is\n\tfrom the branch you're rebasing on (for instance `main` in `git rebase\n\tmain`).\n\n\tThese terms in Git all mean the same thing when dealing with a merge\n\tconflict:\n\n\t* \"common ancestor\" and \"base\". The files from this commit are \"in stage 1\".\n\t* \"ours\", \"us\", and `HEAD`. The files from this commit are \"in stage 2\".\n\t* \"theirs\", \"them\". The files from this commit are \"in stage 3\".\n\n\tIf you're confused about what something like \"deleted by us\" means, it's\n\toften easiest to use some of the tools from\n\t<> above to get more context.\n\tFinding the commit that deleted the file and seeing why is usually more\n\thelpful than trying to abstractly reason through what \"us\" means.\n\n"},{"id":"554203","messageId":"xmqqik3gjc5j.fsf@gitster.g","threadId":"66387","inReplyTo":"e593f3ca-4a03-45a7-b0cc-6295a3a4939f@app.fastmail.com","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-05T17:22:00Z","receivedAt":"2026-10-05T17:22:00Z","isPatch":true,"body":"\"Julia Evans\" writes:\n\n> Marie and I worked on the OURS AND THEIRS section today and I think it's clearer\n> now but also longer (instead of shorter which was my dream). We added an attempt\n> at humor at the end to hopefully help things a bit.\n>\n> \t\"OURS\" AND \"THEIRS\"\n> \t-------------------\n>\n> \tSometimes during a merge conflict, Git will use the terms \"ours\" and\n> \t\"theirs\" (or \"us\" and \"them\"). For example, `git status` might say that\n> \ta file was `deleted by us`.\n>\n> \t\"Ours\" and \"theirs\" are both commits: \"ours\" is the current\n> \t`HEAD` commit, and \"theirs\" is the other side being merged.\n>\n> \tThe first part of a merge conflict (between `<<<<<<<` and `=======`) is\n> \tfrom the \"ours\" side, and the second part (between `=======` and\n> \t`>>>>>>>`) is from the \"theirs\" side.\n>\n> \t----\n> \tFRUITS = [\n> \t \"apple\",\n> \t<<<<<<< HEAD\n> \t \"cherry\", <- ours\n> \t=======\n> \t \"banana\", <- theirs\n> \t>>>>>>> add-fruit\n> \t \"mango\",\n> \t \"orange\",\n> \t]\n> \t----\n>\n> \tDuring a rebase, it can seem \"upside down\" because the \"ours\" commit is\n> \tfrom the branch you're rebasing on (for instance `main` in `git rebase\n> \tmain`).\n>\n> \tThese terms in Git all mean the same thing when dealing with a merge\n> \tconflict:\n>\n> \t* \"common ancestor\" and \"base\". The files from this commit are \"in stage 1\".\n> \t* \"ours\", \"us\", and `HEAD`. The files from this commit are \"in stage 2\".\n> \t* \"theirs\", \"them\". The files from this commit are \"in stage 3\".\n>\n> \tIf you're confused about what something like \"deleted by us\" means, it's\n> \toften easiest to use some of the tools from\n> \t<> above to get more context.\n> \tFinding the commit that deleted the file and seeing why is usually more\n> \thelpful than trying to abstractly reason through what \"us\" means.\n\nMay I ask what is in scope for this effort?\n\nWe previously discussed updating the conflict markers (the 'HEAD'\nand 'add-fruit' labels in the example above). Doing so would\nrequire code changes, which goes beyond mere documentation updates.\nBut if a minor code change like that makes the documentation much\neasier to understand, I think we should consider doing so.\n\nAlong the same line, if git status stopped saying \"deleted by us\"\nand instead used a different phrase, would that help reduce the\n\"upside down\" confusion [*]? Is it acceptable to bend the code\na little if it helps the documentation?\n\n\n[Footnote]\n\n * I suspect that the \"upside down\" feeling is not really about the\n terms \"ours\" and \"theirs\" themselves. Rather, it comes from how\n one conceptualizes what 'rebase' does compared to 'merge'.\n During a rebase, we temporarily pretend that we are working on\n the upstream branch and replay our local changes on top of it.\n Once the user adopts this mindset, displaying the upstream state\n first (the point from which we start building the consolidated\n history) followed by the local state (what was done differently\n by the local side) becomes consistent with how 'merge' displays\n conflicts (where we start from our local state and merge the\n incoming changes).\n\n"},{"id":"554211","messageId":"623cdf71-8076-4967-aff1-3ebeb57d1e3a@app.fastmail.com","threadId":"66387","inReplyTo":"CALnO6CC+h1y=Fu438nm4cd0K-dfPVYq9MqX_+k8fxBU60ot8KA@mail.gmail.com","subject":"Re: [PATCH 0/7] [doc] Add new page on merge conflicts","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-10-05T18:49:56Z","receivedAt":"2026-10-05T18:49:56Z","isPatch":true,"body":"\n\nOn Fri, Oct 2, 2026, at 10:29 PM, D. Ben Knoble wrote:\n> On Fri, Oct 2, 2026 at 1:40 PM Julia Evans wrote:\n>>\n>> Thanks for the review!\n>>\n>> >> * I wrote that git commit does the same thing as git merge --continue\n>> >> during a git merge , but I'm not sure if that's always true.\n>> >\n>> > See also discussion in\n>> > https://lore.kernel.org/git/CABPp-BEQSx4m3BcT28CpVGCtsH75+x3gmv4OJz_ecLVLx+kBWg@mail.gmail.com/T/#t\n>>\n>> Wow, that's a very interesting read. I'm more informed than I was before\n>> I read it but also at the same time more confused :). It makes me think\n>> that \"git commit does the same thing as git merge --continue\" is maybe\n>> not true but also I don't know what the difference might be.\n>>\n>> I've put an item on my TODO list to remove\n>> `git commit does the same thing as git merge --continue`\" and to try to\n>> replace it with a more vague sentence that I guess says you can use\n>> either command without being so specific on whether they are exactly\n>> the same.\n>\n> For now I would say the subtleties in that conversation really make me\n> lean towards the following:\n>\n> - \"git --continue\" is, for most users in most cases, the right\n> thing to do. It's what \"git status\" recommends and will practically\n> never do anything surprising (?).\n\nI was actually surprised to discover that `git status` does not recommend\n`git merge --continue`: it recommends `git commit`.\nMaybe we should change that though?\n\nI agree it makes sense to be consistent with what `git status` recommends.\n\n> - However, it may not always be exactly what you *want*---and you'll\n> usually know when you want to go \"outside\" the normal sequencer and\n> commit directly (because you'll have understood some nuanced details\n> about what can happen).\n>\n> For merge it may be the case that they're the same, I suppose (I'm\n> genuinely not sure), but I would prefer to simplify folks' paths by\n> recommending one of the few uniform interfaces we have :)\n\nThe only other thing that gives me pause about recommending folks\n`git merge --continue` too strongly is that as we know Git users are slow to\nchange their habits, and we don't want to confuse anyone. If someone is\ncurrently using `git commit` I want to know that they can keep doing\nit the same way with no worries.\n\nMaybe if we change `git status` to recommend `git merge --continue`,\nand we think there are no real advantages to using `git commit` instead\nof `git merge --continue`, then we could say something like this:\n\n NOTE: `git commit` is an older alternative to `git merge --continue`.\n You can use either one after resolving a `git merge`.\n\n"},{"id":"554213","messageId":"e2ef9cf9-a87b-4374-bedd-8f7ab1114961@app.fastmail.com","threadId":"66387","inReplyTo":"xmqqik3gjc5j.fsf@gitster.g","subject":"Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page","fromName":"Julia Evans","fromEmail":"julia@jvns.ca","sentAt":"2026-10-05T19:11:21Z","receivedAt":"2026-10-05T19:11:21Z","isPatch":true,"body":">> \tDuring a rebase, it can seem \"upside down\" because the \"ours\" commit is\n>> \tfrom the branch you're rebasing on (for instance `main` in `git rebase\n>> \tmain`).\n>>\n>> \tThese terms in Git all mean the same thing when dealing with a merge\n>> \tconflict:\n>>\n>> \t* \"common ancestor\" and \"base\". The files from this commit are \"in stage 1\".\n>> \t* \"ours\", \"us\", and `HEAD`. The files from this commit are \"in stage 2\".\n>> \t* \"theirs\", \"them\". The files from this commit are \"in stage 3\".\n>>\n>> \tIf you're confused about what something like \"deleted by us\" means, it's\n>> \toften easiest to use some of the tools from\n>> \t<> above to get more context.\n>> \tFinding the commit that deleted the file and seeing why is usually more\n>> \thelpful than trying to abstractly reason through what \"us\" means.\n>\n> May I ask what is in scope for this effort?\n>\n> We previously discussed updating the conflict markers (the 'HEAD'\n> and 'add-fruit' labels in the example above). Doing so would\n> require code changes, which goes beyond mere documentation updates.\n> But if a minor code change like that makes the documentation much\n> easier to understand, I think we should consider doing so.\n>\n> Along the same line, if git status stopped saying \"deleted by us\"\n> and instead used a different phrase, would that help reduce the\n> \"upside down\" confusion [*]? Is it acceptable to bend the code\n> a little if it helps the documentation?\n\nI agree that would make sense. I have some changes to advice\n(on other areas) in local branches on my machine already :)\n\nI think of it as sort of \"documentation driven development\" (write the\ndocumentation, and if it feels upsetting what the documentation is\nsaying, then try to change the code so we're happier with the docs!)\n\nI don't have a clear idea for how to improve the way `git status`\npresents merge conflicts to make it less confusing right now though.\n\nBrainstorming a bit, here's some commentary on this `git status` output:\n\n\tOn branch main\n\tYour branch and 'origin/main' have diverged,\n\tand have 2 and 1 different commits each, respectively.\n\t (use \"git pull\" if you want to integrate the remote branch with yours)\n\n\tYou have unmerged paths.\n\t (fix conflicts and run \"git commit\")\n\t (use \"git merge --abort\" to abort the merge)\n\n\tUnmerged paths:\n\t (use \"git add ...\" to mark resolution)\n\t both modified: fruits.py\n\n\tno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n1. `(use \"git pull\" if you want to integrate the remote branch with yours)`\n is not helpful advice here, it's not even allowed to run `git pull`\n in the middle of a merge conflict.\n2. `git add` is sort of not helpful here, all of the unmerged files currently\n have conflict markers, so the next step is definitely not to run `git add`,\n it's to edit one of the unmerged files. But perhaps it's unrealistic to\n be running the equivalent of `git diff --check` in `git status` just to\n help users out.\n3. Not sure if \"unmerged\" is the best term here, maybe \"conflicted\"?\n4. It gives the advice to use `git add` twice which is weird. \n5. One part of the advice refers to the process of fixing conflicts as\n \"fix conflicts\" but the other part calls it \"mark resolution\". Should\n probably be consistent there.\n\nBut as you can see those comments are all over the place, some of them\nare just wording changes, some of them would involve adding a bunch of\nconditional logic to the advice system that might not be realistic,\nI don't know.\n\n> [Footnote]\n>\n> * I suspect that the \"upside down\" feeling is not really about the\n> terms \"ours\" and \"theirs\" themselves. Rather, it comes from how\n> one conceptualizes what 'rebase' does compared to 'merge'.\n> During a rebase, we temporarily pretend that we are working on\n> the upstream branch and replay our local changes on top of it.\n> Once the user adopts this mindset, displaying the upstream state\n> first (the point from which we start building the consolidated\n> history) followed by the local state (what was done differently\n> by the local side) becomes consistent with how 'merge' displays\n> conflicts (where we start from our local state and merge the\n> incoming changes).\n\nI will say that I know all of these facts but it has never helped\nme to remember \"ours\" and \"theirs\" :). I'm pretty resistant in general\nto telling people they need to adopt the \"right mindset\", IMO\nit's normal for people to have different points of view.\n\nWhen explaining Git I heard a lot of \"yes I know all that but I just\ndon't like to think about it that way\" and it really helped me\nto learn to respect when folks said that and try to see it from\ntheir point of view.\n\n"}]}