On 3/12/2013 16:34, Quoth Edward Diener:
A tool wants to replace this file's data and in doing so it attempts to delete it and then recreate it with the same name. The 'delete' would reduce the reference count to 1. What happens then when the file gets 'created' with the same name ? By create we can also consider 'copy' or 'move' to that same name:
1) The file create fails 2) The file create actually change the file which still exists and increases the hard link reference count to 2
If it does 1) as I suspect, than using the hardlink fails with such a product. If as another poster has ascertained 'git' uses the 'delete' and 'create' method to change the file to a different version, then 'git' will fail. The same goes for any tool that changes the file by deleting it and recreating it if 1) is how things work with hardlinks. OTOH if 2) is the case then there are no problems.
No, that's not how it works. If the file is deleted, the reference count of the *other* copy of the file will go down to 1, and in the local directory there will be no file. If a file with the same name is then created (whether via write, copy, or move), this will succeed but result in an independent file that is not associated with the "other" file at all; changing one will not affect the other. In order to "fix" this, something would have to go through and explicitly recreate the links, possibly inspecting each of the copies to determine which one is "better". (Or be configured to always steamroll one way or the other.)