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

preventing evil merges

From
Sandro Santilli <strk@keybit.net>
Date
May 30, 2013, 16:34 UTC
Message-ID
<20130530163459.GI31679@gnash>

Hey all, I've be burnt by what someone on IRC referred to as "evil merges", that is loss of history after amending a merge commit:

 git merge anotherbranch
 git add something
 git commit --amend

After the steps above the addition of "something" can't be found in the history anymore, but the file is there. Moreover (I think but didn't try to reproruce) a further rebase to a common ancestore of my working branch and "anotherbranch" resulted in further loss of the changes. The only way for me to get them back has been by checking out from reflog.

I've no idea about what was going on but this experience reminded me of another one I had in the past in which we could not figure out when some changes were added into a repository (!).

If amending a merge is so dangerous, would it make sense to require and hard-to-type switch in order for it to really do anything ?

--strk; 
Next: Junio C Hamano
Message 1 of 3 in “preventing evil merges”
  1. Sandro SantilliMay 30, 2013
  2. Junio C HamanoJun 3, 2013
  3. Antoine PelisseJun 3, 2013

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.