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

Re: [BUG] Silent data loss on merge with uncommited changes + renames

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 22, 2013, 15:19 UTC
Message-ID
<7v61zer3s9.fsf@alter.siamese.dyndns.org>
In-Reply-To
<vpqobd6q5nm.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I could have expected "git merge --abort" to fail, but the problem is
> really more serious here: data loss is done silently before giving me an
> opportunity to do or abort anything.

I think this is a well known and longstanding failure case in the recursive merge. As it does not perform its internal operation while handling renames in clean and distinct steps (i.e. figure out what goes to where before touching any index entry or working tree, then check if a proposed change to the index or the working tree conflicts with local changes, and finally carry out the proposed change), it is somewhat hard to fix it correctly in the current implementation, even though you probably could patch these up case by case basis.

Previous: Matthieu Moy
Message 4 of 4 in “[BUG] Silent data loss on merge with uncommited changes + renames”
  1. Matthieu MoyApr 22, 2013
  2. Johannes SixtApr 22, 2013
  3. Matthieu MoyApr 22, 2013
  4. Junio C HamanoApr 22, 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.