git/list[1] front-page[2] threads[3] people[4] search[5] about
wed 2026-10-07 17:22 UTC

Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page

From
Julia Evans <julia@jvns.ca>
Date
Oct 5, 2026, 16:54 UTC
Message-ID
<e593f3ca-4a03-45a7-b0cc-6295a3a4939f@app.fastmail.com>
In-Reply-To
<5ba2088c-4919-465f-8892-4ed0685f81ea@app.fastmail.com>
Show 64 quoted lines
>> [snip]
>>> +[[ours]]
>>> +"OURS" AND "THEIRS"
>>> +-------------------
>>> +
>>> +Git refers to the first part of a merge conflict (between `<<<<<<<`
>>> +and `=======`) as "ours" and the second part (between `=======` and
>>> +`>>>>>>>`) as "theirs".
>>> +
>>> +Normally, "ours" is the commit that was checked out before you started
>>> +the merge, and "theirs" is the other commit.
>>> +
>>> +But when the merge conflict was caused by a `git rebase`, it's the
>>> +opposite: "theirs" is the commit that was checked out before you started
>>> +the merge. This is because under the hood, `git rebase main` checks out
>>> +the `main` commit first before doing the merge operation.
>>
>> Hmm. This part is a bit confusing to me. "ours" is always the commit
>> that's currently checked out, and "theirs" is always the one that is
>> getting merged into the checked-out commit.
>>
>> How about a variant of the following instead?
>>
>>   In a conflict, the side between `<<<<<<<` and `=======` is "ours"
>>   and the side between `=======` and `>>>>>>>` is "theirs". "Ours" is
>>   always the side that `HEAD` points to while the merge happens; "theirs"
>>   is the commit being merged into it.
>>
>>   For `git merge <other>`, `HEAD` is your current branch, so "ours" is
>>   your branch and "theirs" is `<other>`.
>>
>>   For `git rebase <upstream>`, `HEAD` is first moved to `<upstream>` and
>>   your commits are then replayed on top one at a time. So "ours" is the
>>   already-rebased history starting at `<upstream>`, and "theirs" is the
>>   commit from your original branch that is currently being replayed.
>
> Thanks, your suggestion gives me some other ways to think about this.
>
> I think I'll try to write something shorter that is unambiguous, 
> instead of trying
> to use more words to make it feel more intuitive. I don't think I 
> actually know
> anyone who feels it's easy to understand the way merge conflicts are
> presented, and more explanation may not help.
>
> It might be more useful here to encourage (again) folks to use one of the many
> amazing tools available (in the "tools" section) to get more context.
>
>>> +These terms in Git all mean the same thing when dealing with a merge
>>> +conflict:
>>> +
>>> +* "common ancestor", "base", and "stage 1"
>>> +* "ours", "us", "stage 2", and `HEAD`
>>> +* "theirs", "them", and "stage 3"
>>
>> I wouldn't say that "stage N" is equivalent to the respective other
>> terms. These stages rather refer to the different versions of a specific
>> file as recorded in the index, they do not indicate a specific commit.
>> In contrast to that, all the other terms may also indicate a specific
>> version of a file, but may also refer to the commits.
>
> Thanks, will try to figure out how to make it more accurate.
> We could also refer to gitdatamodel if folks want to learn what the
> term "stage" means too.

Marie and I worked on the OURS AND THEIRS section today and I think it's clearer now but also longer (instead of shorter which was my dream). We added an attempt at humor at the end to hopefully help things a bit.

	"OURS" AND "THEIRS"
	-------------------
	Sometimes during a merge conflict, Git will use the terms "ours" and
	"theirs" (or "us" and "them"). For example, `git status` might say that
	a file was `deleted by us`.
	"Ours" and "theirs" are both commits: "ours" is the current
	`HEAD` commit, and "theirs" is the other side being merged.
	The first part of a merge conflict (between `<<<<<<<` and `=======`) is
	from the "ours" side, and the second part (between `=======` and
	`>>>>>>>`) is from the "theirs" side.
	----
	FRUITS = [
	    "apple",
	<<<<<<< HEAD
	    "cherry",                      <- ours
	=======
	    "banana",                      <- theirs
	>>>>>>> add-fruit
	    "mango",
	    "orange",
	]
	----
	During a rebase, it can seem "upside down" because the "ours" commit is
	from the branch you're rebasing on (for instance `main` in `git rebase
	main`).
	These terms in Git all mean the same thing when dealing with a merge
	conflict:
	* "common ancestor" and "base". The files from this commit are "in stage 1".
	* "ours", "us", and `HEAD`. The files from this commit are "in stage 2".
	* "theirs", "them". The files from this commit are "in stage 3".
	If you're confused about what something like "deleted by us" means, it's
	often easiest to use some of the tools from
	<<tools,TOOLS FOR HANDLING MERGE CONFLICTS>> above to get more context.
	Finding the commit that deleted the file and seeing why is usually more
	helpful than trying to abstractly reason through what "us" means.
Previous: Junio C HamanoNext: Junio C Hamano
Message 41 of 46 in “[doc] Add new page on merge conflicts”
  1. 0/7 [doc] Add new page on merge conflictsJulia Evans via GitGitGadget, Sep 24, 2026
  2. 1/7 [doc] Add new gitmergeconflicts man pageJulia Evans via GitGitGadget, Sep 24, 2026
  3. 2/7 [doc] git-merge: link to new merge conflicts guideJulia Evans via GitGitGadget, Sep 24, 2026
  4. 3/7 [doc] git-rebase: link to new merge conflicts guideJulia Evans via GitGitGadget, Sep 24, 2026
  5. 4/7 [doc] git-revert: link to new merge conflicts guideJulia Evans via GitGitGadget, Sep 24, 2026
  6. 5/7 [doc] git-cherry-pick: link to new merge conflicts guideJulia Evans via GitGitGadget, Sep 24, 2026
  7. 6/7 [doc] git-pull: link to new merge conflicts guideJulia Evans via GitGitGadget, Sep 24, 2026
  8. 7/7 [doc] ignore conflict markers in gitmergeconflicts.adocJulia Evans via GitGitGadget, Sep 24, 2026
  9. Junio C HamanoSep 24, 2026
  10. Junio C HamanoSep 24, 2026
  11. Junio C HamanoSep 24, 2026
  12. Jeff KingSep 24, 2026
  13. D. Ben KnobleSep 25, 2026
  14. D. Ben KnobleSep 25, 2026
  15. Julia EvansSep 25, 2026
  16. Junio C HamanoSep 25, 2026
  17. Junio C HamanoSep 25, 2026
  18. Ben KnobleSep 25, 2026
  19. Ben KnobleSep 25, 2026
  20. Junio C HamanoSep 25, 2026
  21. Julia EvansSep 28, 2026
  22. Julia EvansSep 28, 2026
  23. Junio C HamanoSep 28, 2026
  24. Jeff KingSep 29, 2026
  25. Junio C HamanoSep 29, 2026
  26. Patrick SteinhardtSep 30, 2026
  27. Patrick SteinhardtSep 30, 2026
  28. Julia EvansSep 30, 2026
  29. Junio C HamanoSep 30, 2026
  30. Patrick SteinhardtOct 1, 2026
  31. Julia EvansOct 1, 2026
  32. Julia EvansOct 2, 2026
  33. Julia EvansOct 2, 2026
  34. Junio C HamanoOct 2, 2026
  35. Junio C HamanoOct 2, 2026
  36. Julia EvansOct 2, 2026
  37. Junio C HamanoOct 2, 2026
  38. D. Ben KnobleOct 3, 2026
  39. D. Ben KnobleOct 3, 2026
  40. Junio C HamanoOct 3, 2026
  41. Julia EvansOct 5, 2026
  42. Junio C HamanoOct 5, 2026
  43. Julia EvansOct 5, 2026
  44. Julia EvansOct 5, 2026
  45. D. Ben KnobleOct 6, 2026
  46. D. Ben KnobleOct 6, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.