Thanks for the clarification and verification of that expected behaviour Junio. I shall keep this in mind. Regards Gary On 12/04/12 19:32, Junio C Hamano wrote: > Gary Wilson <gary.wilson@xxxxxxxxxxxxxxxxx> writes: > >> Use case to replicate: >> >> 1. Have path/files/a.file exists (and/or path/files/*) on client A and >> client B >> 2. Remove the physical files from the path/files/ directory on client A, >> so that the directory is empty >> 3. git commit >> 4. git pull on client B >> 5. On client A an empty path/files/ directory exists on client B it has >> been removed, meaning path/files/ no longer exists. >> >> Is this the expected behaviour? > As Git does not track directories at all, but merely uses directories as a > means to instantiate files (which it tracks), when the last file is > removed as the result of a merge in repository B, it notices that the > directory is no longer needed to hold anything it cares about, and removes > it. > > If you ran "git rm path/files/a.file" in repository A to remove the last > file in the directory may also remove the now-empty directory (I do not > remember offhand if it does), which is also expected. > -- 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