git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Documentation: document pitfalls with 3-way merge

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Dec 8, 2013, 22:40 UTC
Message-ID
<20131208224013.GC9108@google.com>
In-Reply-To
<1386535227-209788-1-git-send-email-sandals@crustytoothpaste.net>
Hi,
brian m. carlson wrote:
> Oftentimes people will make the same change in two branches, revert the change
> in one branch, and then be surprised when a merge reinstitutes that change when
> the branches are merged.

Life is even more complicated: if the merge-base chosen happens to be a descendent of the change on both branches, the merge won't reinstate the change.

The problem scenario hasn't happened to me recently. Can you give an example of how it happens? Why is the same change being made independently on two different branches? I'm wondering because such a story could make the example in the documentation a little clearer and avoid having to make the explanation overly technical.

In any event, that the 3-way merge is really just a stupid 3-way merge (modulo multiple merge base madness) does seem worth emphasizing, so thanks for working on this.

Hope that helps, Jonathan

Previous: brian m. carlsonNext: brian m. carlson
Message 2 of 3 in “Documentation: document pitfalls with 3-way merge”
  1. Documentation: document pitfalls with 3-way mergebrian m. carlson, Dec 8, 2013
  2. Jonathan NiederDec 8, 2013
  3. brian m. carlsonDec 8, 2013

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.