From: Gary Wilson <gary.wilson@of-networks.co.uk>
Date: Thu, 12 Apr 2012 19:11:07 GMT
Subject: Re: Unexpected empty directory removal
Message-ID: <4F8728CB.2030201@of-networks.co.uk>
In-Reply-To: <7vehrs6bt1.fsf@alter.siamese.dyndns.org>

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@of-networks.co.uk> 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.
>