{"thread":{"id":"29480","subject":"git rebase and MacOS 10.7.2 file versions","startedAt":"2012-01-30T16:46:45Z","lastAt":"2012-01-30T19:11:23Z","messageCount":2,"participants":["Thomas Röfer","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183336","messageId":"A9AB7E23-3C22-4BCC-8E25-EF2D66B57E61@dfki.de","threadId":"29480","inReplyTo":null,"subject":"git rebase and MacOS 10.7.2 file versions","fromName":"Thomas Röfer","fromEmail":"thomas.roefer@dfki.de","sentAt":"2012-01-30T16:46:45Z","receivedAt":"2012-01-30T16:46:45Z","isPatch":false,"sender":{"key":"thomas.roefer@dfki.de","avatar":null},"body":"Hi,\n\nI 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.\n\nWhat 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.\n\nI have tested this with a number of git versions, but the behavior is always the same.\n\nAll this may simply be a bug in MacOS 10.7.x, but maybe there is a workaround for git to make this work again.\n\nBest regards,\n\nThomas Röfer\n"},{"id":"183365","messageId":"4F26EB5B.4000907@web.de","threadId":"29480","inReplyTo":"A9AB7E23-3C22-4BCC-8E25-EF2D66B57E61@dfki.de","subject":"Re: git rebase and MacOS 10.7.2 file versions","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-01-30T19:11:23Z","receivedAt":"2012-01-30T19:11:23Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 30.01.12 17:46, Thomas Röfer wrote:\n> Hi,\n> \n> 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.\n> \n> 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.\n> \n> I have tested this with a number of git versions, but the behavior is always the same.\n> \n> 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.\n> \n> Best regards,\n> \n> Thomas Röfer\nHi,\n\nis that problem reproducable? It seems so.\n\nCould provide a simple demo, what you have done and how to reproduce the error?\n \nIf that is the case, chances that we can reproduce it are much better.\nAnd so are the chances that somebody reading this list can help you.\n\n>Lion's \"file versions\" feature..\nAre the files identical when you run e.g. md5sum on them?\nAnd what does a simple \"ls\" from a terminal say?\n\n\n/Torsten\n"}]}