# Unexpected empty directory removal

3 messages from 2012-04-12 to 2012-04-12. Participants: Gary Wilson, Junio C Hamano.
Thread: https://gitlist.dev/t/30225

## Gary Wilson, 2012-04-12 17:08

Subject: Unexpected empty directory removal
Message-ID: <4F870C04.9060304@of-networks.co.uk>
URL: https://gitlist.dev/e/4F870C04.9060304%40of-networks.co.uk

```
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, 2012-04-12 18:32

Subject: Re: Unexpected empty directory removal
Message-ID: <7vehrs6bt1.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vehrs6bt1.fsf%40alter.siamese.dyndns.org
In-Reply-To: <4F870C04.9060304@of-networks.co.uk>

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

```

## Gary Wilson, 2012-04-12 19:11

Subject: Re: Unexpected empty directory removal
Message-ID: <4F8728CB.2030201@of-networks.co.uk>
URL: https://gitlist.dev/e/4F8728CB.2030201%40of-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.
>

```