On 30.01.12 17:46, Thomas Röfer wrote: > 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 Hi, is that problem reproducable? It seems so. Could provide a simple demo, what you have done and how to reproduce the error? If that is the case, chances that we can reproduce it are much better. And so are the chances that somebody reading this list can help you. >Lion's "file versions" feature.. Are the files identical when you run e.g. md5sum on them? And what does a simple "ls" from a terminal say? /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html