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

Re: Cleaning up history with git rebase

From
Michael Witten <mfwitten@gmail.com>
Date
Jul 31, 2011, 21:33 UTC
Message-ID
<CAMOZ1BvRDSkzJmASNFQvZ-SVBUXZHw6CyfLP4SJqK8CwaMMDUA@mail.gmail.com>
In-Reply-To
<34ca77f818944acb9f5c6f19d91df73f-mfwitten@gmail.com>
On Sun, Jul 31, 2011 at 20:21, Michael Witten <mfwitten@gmail.com> wrote:
> Why are there conflicts anyway?
Oh...

I guess there were conflicts when the merge commit was made in the original repository, and these conflicts were resolved by the merge commit itself. Hence, when rebase tries to split up a merge by dealing with just the non-merge parents, you end up having to deal with the conflict again.

Shouldn't rebase take this into account?
Previous: Michael WittenNext: Ricky Egeland
Message 3 of 12 in “Cleaning up history with git rebase”
  1. Ricky EgelandJul 31, 2011
  2. Michael WittenJul 31, 2011
  3. Michael WittenJul 31, 2011
  4. Ricky EgelandJul 31, 2011
  5. Michael WittenAug 1, 2011
  6. Michael WittenAug 1, 2011
  7. pbegelandAug 3, 2011
  8. Michael WittenAug 4, 2011
  9. pbegelandAug 5, 2011
  10. Michael WittenAug 6, 2011
  11. pbegelandAug 9, 2011
  12. Michael WittenAug 4, 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.