Re: why still no empty directory support in git

On Tue, 30 Dec 2008, demerphq wrote:

Delivering mail into a Maildir is a three-step process. Let's say we are delivering to a Maildir spool stored in ~/Maildir.

(1)

The message is written out to ~/Maildir/tmp/some_filename.

(2)

When the message is complete, it is rename()d to ~/Maildir/new/some_name.

(3)

When a mail user agent reads the Maildir spool, it checks new/ for new mail. If there is a message there, it renames it to ~/Maildir/cur/some_other_filename and announces to the user, "You've got mail!"

So, let's say I take your suggestion.

$ touch ~/Maildir/new/.exists $ git add ~/Maildir/new/.exists && git commit -m "La di da"

Now a spec-compliant Maildir user agent will attempt to deliver this new "email message" of zero bytes into the mail spool and assign it a message UID. Doing so will remove it from Maildir/new.

Then I do "git pull" to get the new messages from my mail server's Maildir repository for my email. This causes git read-tree to eventually be run. If the new tree has no unprocessed email, git runs rmdir() on ~/Maildir/new/.

Now if I want to write a new email to ~/Maildir/ (such as due to copying an email from another folder), the Maildir user agent suddenly finds itself in a strange place: new/ does not exist, violating the definition of a Maildir. This breaks mail processing for that ~/Maildir/ folder.

This is because git is removing these directories. There is a strict incompatibility between git rmdir()ing empty directories behind my back and Maildir systems.

I hope that explains the issue I face, both to Junio and to Yves.

Note that for me, there is no issue with how to handle merging of empty directories, or what happens if these empty directories become files, or which empty directories to keep around; if git just never rmdir()s any directories for me, and otherwise acts identically to now, that would solve my problem. I can look into preparing an RFC patch that creates a mode like that.

-- Asheesh.