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

Re: Converting merge to rebase in the presence of conflicts

From
Johannes Sixt <j.sixt@viscovery.net>
Date
Apr 12, 2011, 06:11 UTC
Message-ID
<4DA3ECFD.7060202@viscovery.net>
In-Reply-To
<BANLkTinVUdmG56oPQXvMhFh6hLcFj3_jZg@mail.gmail.com>
Please don't cull Cc list; use "Reply to all" in your MUA.
Am 4/11/2011 17:15, schrieb Hrvoje Nikšić:
> I still wonder why rerere is necessary here. After all, even without
> the rerere metadata, the information about conflict resolution is
> right there, in the merge commit, and rebase could conceivably make
> use of it. What am I missing?

The conflicts that you see during a merge may be attributed to several different commits of the merged branch. Therefore, when you rebase the branch, you will see different subsets of the conflicts for each rebased commit, and it is possible that you see conflicts that you did not see in the merge. How can you expect rebase to "know" how to resolve them?

-- Hannes
Previous: Michael Haggerty
Message 6 of 6 in “Converting merge to rebase in the presence of conflicts”
  1. Hrvoje NikšićApr 11, 2011
  2. Michael J GruberApr 11, 2011
  3. Johannes SixtApr 11, 2011
  4. Hrvoje NikšićApr 11, 2011
  5. Michael HaggertyApr 12, 2011
  6. Johannes SixtApr 12, 2011

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.