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

Re: Git deletes files when rebasing an amended merge-commit.

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 8, 2015, 16:06 UTC
Message-ID
<xmqqegh5s5u8.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CAJqY2NUHg-7ghiNA7m+Q36LPhgG6tC6QDg2BP6f52fvDv6uAWQ@mail.gmail.com>
Hans Weltar <hansweltar@gmail.com> writes:
> When you have a fast-forwardable merge commit, you can amend this
> commit to hold additional changes.

The real issue may be that there is a difference between "you can" and "it is a good idea to", though ;-)

I think the fast-forwardable-ness is a red herring in your example; rebase by default replays the patches commit by commit to flatten the history, and evil merges where your result does not match a mechanical merge result will be lost, and that is true even if you were dealing with a real merge.

I'd imagine that you would need something like
http://thread.gmane.org/gmane.comp.version-control.git/198125/focus=198516

where it proposes a mode of rebase that picks the change in the first parent chain.

Thanks.
Previous: Hans Weltar
Message 2 of 2 in “Git deletes files when rebasing an amended merge-commit.”
  1. Hans WeltarOct 8, 2015
  2. Junio C HamanoOct 8, 2015

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.