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

Re: rebase -p loses amended changes

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 4, 2012, 17:11 UTC
Message-ID
<7vpqbna0cd.fsf@alter.siamese.dyndns.org>
In-Reply-To
<4F7BEA9F.3060805@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
Show 9 quoted lines
> IMO, it is a sub-optimal implementation of rebase -p that it attempts to
> redo the merge. A better strategy is to just replay the changes between
> the first parent and the merge commit, and then generate a new merge commit:
>
>    git diff-tree -p M^ M | git apply --index &&
>    git rev-parse M^2 > .git/MERGE_HEAD &&
>    git commit -c M
>
> This would side-step all the issues discussed here, no?
Or cherry-pick the change made by the merge to its first parent, i.e.
	git cherry-pick -m 1 M
Previous: Johannes SixtNext: Junio C Hamano
Message 9 of 18 in “Re: rebase -p loses amended changes”
  1. Jon SeymourMar 31, 2012
  2. Thomas RastMar 31, 2012
  3. Jon SeymourMar 31, 2012
  4. J Robert RayApr 3, 2012
  5. Jon SeymourApr 3, 2012
  6. Junio C HamanoApr 3, 2012
  7. Phil HordApr 3, 2012
  8. Johannes SixtApr 4, 2012
  9. Junio C HamanoApr 4, 2012
  10. Junio C HamanoApr 4, 2012
  11. Jon SeymourApr 4, 2012
  12. Junio C HamanoApr 4, 2012
  13. Jon SeymourApr 4, 2012
  14. Junio C HamanoApr 4, 2012
  15. Martin von ZweigbergkApr 5, 2012
  16. Jon SeymourApr 5, 2012
  17. Martin von ZweigbergkApr 5, 2012
  18. Johannes SixtApr 10, 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.