threads / discuss / 30225

Unexpected empty directory removal

Subject: Unexpected empty directory removal

## tl;dr

3 messages between Apr 12, 2012 and Apr 12, 2012.

replies: 2people: 2as markdown or json

Gary Wilson· Apr 12, 2012, 17:08 UTC · lore

Hi

I do not normally report things such as this and they are usually "features", however this one seems overly strange to me as directories and files are different things and I would expected a source code versioning system to adhere to that.

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 if it is, I will definitely bear that in mind and note that git will not make empty directories AND will remove empty directories from all clients apart from the client that emptied the directory.

client A: git version 1.7.0.4 client B: git version 1.7.1 git server: whatever github.com is running

Regards Gary

Junio C Hamano· Apr 12, 2012, 18:32 UTC · re: Gary Wilson · lore

Re: Unexpected empty directory removal

Gary Wilson <gary.wilson@of-networks.co.uk> writes:

Show 12 quoted lines

> 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.

Gary Wilson· Apr 12, 2012, 19:11 UTC · re: Junio C Hamano · lore

Re: Unexpected empty directory removal

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:

Show 24 quoted lines

> 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.
>