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

git rebase and MacOS 10.7.2 file versions

From
TRThomas Röfer <thomas.roefer@dfki.de>
Date
Jan 30, 2012, 16:46 UTC
Message-ID
<A9AB7E23-3C22-4BCC-8E25-EF2D66B57E61@dfki.de>
Hi,
I get mysterious behavior during git rebase on MacOS 10.7.x. git reports unresolvable conflicts, stops the rebase, but afterwards the list of files that needs to be fixed is empty. git rebase --skip does not help, because then the commit is actually missing.
What helps is to abort the rebase, copy the conflicting files, delete the originals and move back the copies instead. The files themselves are identical before deleting and after restoring and their access rights are also unchanged. What is actually different is that all the conflicting files so far had older versions stored by Lion's "file versions" feature. The restored copies do not have such a version history. Since "file versions" cannot be deactivated, editing a file with an application that supports it (e.g. TextEdit) will basically result in strange git conflicts later.
I have tested this with a number of git versions, but the behavior is always the same.
All this may simply be a bug in MacOS 10.7.x, but maybe there is a workaround for git to make this work again.
Best regards,
Thomas Röfer
Next: Torsten Bögershausen
Message 1 of 2 in “git rebase and MacOS 10.7.2 file versions”
  1. Thomas RöferJan 30, 2012
  2. Torsten BögershausenJan 30, 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.