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

Re: [PATCH/RFC] rebase -p: do not redo the merge, but cherry-pick first-parent changes

From
Junio C Hamano <gitster@pobox.com>
Date
May 22, 2012, 18:23 UTC
Message-ID
<7vobpg3wj6.fsf@alter.siamese.dyndns.org>
In-Reply-To
<4FBAA33D.1080703@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
Show 5 quoted lines
> When rebase -p had to replay a merge commit, it used to redo the merge.
> But this has drawbacks:
>
> - When the merge was evil, i.e., contained changes that are in neither of
>   the parents, that change was not preserved.

This is a desiable property, and not necessarily limited to "evil" merges but also applies to everyday conflict resolutions. Replaying the change between the merge and its first parent is a way to achieve it, but I think it also has downsides. If you are replaying a merge to an updated history that already contains a part of what is merged, some part of the difference between the original merge and its first parent already exists in the commit that the will become the first parent of the replayed merge.

> - The 'git merge' invocation passed the commit message of the old merge
>   commit, but it still obeyed the merge.log option. If it was set, the log
>   ended up twice in the commit message.

This should be fixed independent of this patch, no? Is it a matter of just passing --no-log or something, or is there anything more elaborate necessary?

Previous: Johannes SixtNext: Johannes Sixt
Message 2 of 16 in “rebase -p: do not redo the merge, but cherry-pick first-parent changes”
  1. rebase -p: do not redo the merge, but cherry-pick first-parent changesJohannes Sixt, May 21, 2012
  2. Junio C HamanoMay 22, 2012
  3. Johannes SixtMay 22, 2012
  4. Jonathan NiederMay 22, 2012
  5. Martin von ZweigbergkMay 23, 2012
  6. Junio C HamanoMay 23, 2012
  7. Martin von ZweigbergkMay 23, 2012
  8. Junio C HamanoMay 24, 2012
  9. Martin von ZweigbergkMay 24, 2012
  10. Junio C HamanoMay 24, 2012
  11. Johannes SixtMay 24, 2012
  12. Junio C HamanoMay 24, 2012
  13. Johannes SixtMay 25, 2012
  14. Junio C HamanoMay 25, 2012
  15. Johannes SixtMay 25, 2012
  16. Johannes SixtMay 23, 2012

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.