{"thread":{"id":"16922","subject":"why still no empty directory support in git","startedAt":"2008-12-30T03:42:26Z","lastAt":"2009-01-08T07:12:57Z","messageCount":18,"participants":["Ping Yin","Asheesh Laroia","Jeff Whiteside","Liu Yubao","Robin Rosenberg","Junio C Hamano","demerphq","Johannes Schindelin","Michael Gaber","David Brown","Anatol Pomozov","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98936","messageId":"46dff0320812291942y6aeec941k9394586621e9151b@mail.gmail.com","threadId":"16922","inReplyTo":null,"subject":"why still no empty directory support in git","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-12-30T03:42:26Z","receivedAt":"2008-12-30T03:42:26Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"Yes, i know this topic has been discussed for many times. However, i\nam still not clear about the real reason.\n\nSo which is the reason?\n\n1. it's by design, intentional\n2. unclear logic, for example, whether to remove the directory after\nthe last file in it is deleted\n3. hard work, no one has picked it yet\n4. hardly done in current model\n\nPing Yin\n"},{"id":"98945","messageId":"alpine.DEB.2.00.0812300008060.31590@vellum.laroia.net","threadId":"16922","inReplyTo":"46dff0320812291942y6aeec941k9394586621e9151b@mail.gmail.com","subject":"Re: why still no empty directory support in git","fromName":"Asheesh Laroia","fromEmail":"asheesh@asheesh.org","sentAt":"2008-12-30T05:10:04Z","receivedAt":"2008-12-30T05:10:04Z","isPatch":false,"sender":{"key":"asheesh@asheesh.org","avatar":"https://avatars.githubusercontent.com/u/25457?v=4"},"body":"On Tue, 30 Dec 2008, Ping Yin wrote:\n\n> 2. unclear logic, for example, whether to remove the directory after the \n> last file in it is deleted\n\nThis is the thing I dislike most about git: that it sometimes calls \nrmdir() for me.  At least, one should be able to turn it off in a \nper-repository basis.  I'm going to see how hard a patch that would be to \nwrite.\n\n> 3. hard work, no one has picked it yet\n\nThis is what I recall.\n\n-- Asheesh.\n\n-- \nWriting is turning one's worst moments into money.\n \t\t-- J.P. Donleavy\n"},{"id":"98946","messageId":"3ab397d0812292128j65e2e1e1xf403a998f4653aac@mail.gmail.com","threadId":"16922","inReplyTo":"alpine.DEB.2.00.0812300008060.31590@vellum.laroia.net","subject":"Re: why still no empty directory support in git","fromName":"Jeff Whiteside","fromEmail":"jeff.m.whiteside@gmail.com","sentAt":"2008-12-30T05:28:58Z","receivedAt":"2008-12-30T05:28:58Z","isPatch":false,"sender":{"key":"jeff.m.whiteside@gmail.com","avatar":null},"body":"funny, i thought it was 1, by design.\n\nbut i forget why a tree object couldn't point to an empty blob.\n"},{"id":"98950","messageId":"4959BB07.6000106@gmail.com","threadId":"16922","inReplyTo":"46dff0320812291942y6aeec941k9394586621e9151b@mail.gmail.com","subject":"Re: why still no empty directory support in git","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2008-12-30T06:09:11Z","receivedAt":"2008-12-30T06:09:11Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Ping Yin wrote:\n> Yes, i know this topic has been discussed for many times. However, i\n> am still not clear about the real reason.\n> \n> So which is the reason?\n> \n> 1. it's by design, intentional\nIt's saied somewhere git is a \"stupid content tracker\", it cares file content\nnot file name, and empty directories will complicate the merge algorithm\nunnecessarily.\n\n> 2. unclear logic, for example, whether to remove the directory after\n> the last file in it is deleted\n> 3. hard work, no one has picked it yet\n> 4. hardly done in current model\n> \n> Ping Yin\n"},{"id":"98951","messageId":"alpine.DEB.2.00.0812300113050.22107@vellum.laroia.net","threadId":"16922","inReplyTo":"alpine.DEB.2.00.0812300008060.31590@vellum.laroia.net","subject":"Re: why still no empty directory support in git","fromName":"Asheesh Laroia","fromEmail":"asheesh@asheesh.org","sentAt":"2008-12-30T06:25:41Z","receivedAt":"2008-12-30T06:25:41Z","isPatch":false,"sender":{"key":"asheesh@asheesh.org","avatar":"https://avatars.githubusercontent.com/u/25457?v=4"},"body":"On Tue, 30 Dec 2008, Asheesh Laroia wrote:\n\n> On Tue, 30 Dec 2008, Ping Yin wrote:\n>\n>> 2. unclear logic, for example, whether to remove the directory after the \n>> last file in it is deleted\n>\n> This is the thing I dislike most about git: that it sometimes calls rmdir() \n> for me.  At least, one should be able to turn it off in a per-repository \n> basis.  I'm going to see how hard a patch that would be to write.\n\nWell, changing this behavior seems to be \"as easy as\" changing \nunlink_entry in unpack_trees.c to not always rmdir(). The most naive thing \nI can think of is to have unlink_entry in unpack_trees check against the \ngit config. It's probably more sensible for unpack_trees to be passed an \nargument that determines if it rmdir()s; that argument could be set via \nargv at \"git unpack-tree\" time, which could be set out of a configuration \nvalue read at \"git\" time.\n\nWould a change of the \"more sensible\" kind possibly be accepted by the git \nmaintainer?\n\nI ask about this because I'm using git to track email in Maildir \nrepositories, and in that vein I'm getting bitten by git's removal of \nempty directories.\n\n-- Asheesh.\n\n-- \nYou will gain money by an illegal action.\n"},{"id":"98952","messageId":"200812300758.41988.robin.rosenberg.lists@dewire.com","threadId":"16922","inReplyTo":"3ab397d0812292128j65e2e1e1xf403a998f4653aac@mail.gmail.com","subject":"Re: why still no empty directory support in git","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-12-30T06:58:41Z","receivedAt":"2008-12-30T06:58:41Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 30 december 2008 06:28:58 skrev Jeff Whiteside:\n> funny, i thought it was 1, by design.\nSure, but designs can be changed.\n\n> \n> but i forget why a tree object couldn't point to an empty blob.\n\nIt can, but that's not the same.\n\nYou can have an empty tree, but the index doesn't store them, \nso they would be lost on checkout/commit. Linus sketched a solution, \nbut nobody took the bait. Seems doable if anyone really wants it, but\nI'm certain it adds a lot of special cases.\n\nLook for a discussion [RFC PATCH] Re: Empty directories... posted on 2007-07-19.\nIt's in the middle of a long thread.\n\n-- robin\n"},{"id":"98953","messageId":"7viqp25coh.fsf@gitster.siamese.dyndns.org","threadId":"16922","inReplyTo":"200812300758.41988.robin.rosenberg.lists@dewire.com","subject":"Re: why still no empty directory support in git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-30T07:45:18Z","receivedAt":"2008-12-30T07:45:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:\n\n> You can have an empty tree, but the index doesn't store them, so they\n> would be lost on checkout/commit. Linus sketched a solution, but nobody\n> took the bait. Seems doable if anyone really wants it, but I'm certain\n> it adds a lot of special cases.\n\nI think the original poster covered that \"a lot of special cases\" as\n\"unclear semantics\", and there are more.  Do you want to have the presense\nof empty directory \"sticky\"?  Perhaps it later becomes non-empty at some\npoint; will the \"will always present\" attribute kept then?  What happens\nwhen such a directory becomes empty later?  What should happen when a\nbranch that has such a directory with \"sticky existence\" and another\nbranch with the same directory but without the stickiness are merged?\n\nBut I think one bigger reason missing from the list is that many people\nloudly talked about \"wants\", but nobody made convincing argument on\n\"needs\" of such a feature.\n"},{"id":"98956","messageId":"9b18b3110812300043l55a42f6sd995f36bf857543e@mail.gmail.com","threadId":"16922","inReplyTo":"alpine.DEB.2.00.0812300113050.22107@vellum.laroia.net","subject":"Re: why still no empty directory support in git","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2008-12-30T08:43:07Z","receivedAt":"2008-12-30T08:43:07Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2008/12/30 Asheesh Laroia <asheesh@asheesh.org>:\n> On Tue, 30 Dec 2008, Asheesh Laroia wrote:\n>\n>> On Tue, 30 Dec 2008, Ping Yin wrote:\n>>\n>>> 2. unclear logic, for example, whether to remove the directory after the\n>>> last file in it is deleted\n>>\n>> This is the thing I dislike most about git: that it sometimes calls\n>> rmdir() for me.  At least, one should be able to turn it off in a\n>> per-repository basis.  I'm going to see how hard a patch that would be to\n>> write.\n>\n> Well, changing this behavior seems to be \"as easy as\" changing unlink_entry\n> in unpack_trees.c to not always rmdir(). The most naive thing I can think of\n> is to have unlink_entry in unpack_trees check against the git config. It's\n> probably more sensible for unpack_trees to be passed an argument that\n> determines if it rmdir()s; that argument could be set via argv at \"git\n> unpack-tree\" time, which could be set out of a configuration value read at\n> \"git\" time.\n>\n> Would a change of the \"more sensible\" kind possibly be accepted by the git\n> maintainer?\n>\n> I ask about this because I'm using git to track email in Maildir\n> repositories, and in that vein I'm getting bitten by git's removal of empty\n> directories.\n\nAdd a .exists to each directory.  There is precedent for such an\napproach in other systems.\n\ncheers,\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"98957","messageId":"alpine.DEB.2.00.0812300346040.19911@vellum.laroia.net","threadId":"16922","inReplyTo":"9b18b3110812300043l55a42f6sd995f36bf857543e@mail.gmail.com","subject":"Re: why still no empty directory support in git","fromName":"Asheesh Laroia","fromEmail":"asheesh@asheesh.org","sentAt":"2008-12-30T08:58:46Z","receivedAt":"2008-12-30T08:58:46Z","isPatch":false,"sender":{"key":"asheesh@asheesh.org","avatar":"https://avatars.githubusercontent.com/u/25457?v=4"},"body":"On Tue, 30 Dec 2008, demerphq wrote:\n\n> 2008/12/30 Asheesh Laroia <asheesh@asheesh.org>:\n\n>> I ask about this because I'm using git to track email in Maildir \n>> repositories, and in that vein I'm getting bitten by git's removal of \n>> empty directories.\n>\n> Add a .exists to each directory.  There is precedent for such an \n> approach in other systems.\n\nDelivering mail into a Maildir is a three-step process.  Let's say \nwe are delivering to a Maildir spool stored in ~/Maildir.\n\n(1)\n\nThe message is written out to ~/Maildir/tmp/some_filename.\n\n(2)\n\nWhen the message is complete, it is rename()d to \n~/Maildir/new/some_name.\n\n(3)\n\nWhen a mail user agent reads the Maildir spool, it checks new/ for new \nmail. If there is a message there, it renames it to \n~/Maildir/cur/some_other_filename and announces to the user, \"You've got \nmail!\"\n\nSo, let's say I take your suggestion.\n\n$ touch ~/Maildir/new/.exists\n$ git add ~/Maildir/new/.exists && git commit -m \"La di da\"\n\nNow a spec-compliant Maildir user agent will attempt to deliver this new \n\"email message\" of zero bytes into the mail spool and assign it a message \nUID.  Doing so will remove it from Maildir/new.\n\nThen I do \"git pull\" to get the new messages from my mail server's Maildir \nrepository for my email.  This causes git read-tree to eventually be run. \nIf the new tree has no unprocessed email, git runs rmdir() on \n~/Maildir/new/.\n\nNow if I want to write a new email to ~/Maildir/ (such as due to copying \nan email from another folder), the Maildir user agent suddenly finds \nitself in a strange place: new/ does not exist, violating the definition \nof a Maildir. This breaks mail processing for that ~/Maildir/ folder.\n\nThis is because git is removing these directories. There is a strict \nincompatibility between git rmdir()ing empty directories behind my back \nand Maildir systems.\n\nI hope that explains the issue I face, both to Junio and to Yves.\n\nNote that for me, there is no issue with how to handle merging of empty \ndirectories, or what happens if these empty directories become files, or \nwhich empty directories to keep around; if git just never rmdir()s any \ndirectories for me, and otherwise acts identically to now, that would \nsolve my problem. I can look into preparing an RFC patch that creates a \nmode like that.\n\n-- Asheesh.\n\n-- \nYou will be the last person to buy a Chrysler.\n"},{"id":"98963","messageId":"alpine.DEB.1.00.0812301308530.30769@pacific.mpi-cbg.de","threadId":"16922","inReplyTo":"46dff0320812291942y6aeec941k9394586621e9151b@mail.gmail.com","subject":"Re: why still no empty directory support in git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-12-30T12:09:41Z","receivedAt":"2008-12-30T12:09:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Dec 2008, Ping Yin wrote:\n\n> Yes, i know this topic has been discussed for many times.\n\nWe have empty directory support in Git.  It works like this: for \ndirectories that you do want to keep, you add an empty .gitignore file.\n\nNo problem at all,\nDscho\n"},{"id":"98974","messageId":"495A2E61.3030702@gmx.net","threadId":"16922","inReplyTo":"alpine.DEB.1.00.0812301308530.30769@pacific.mpi-cbg.de","subject":"Re: why still no empty directory support in git","fromName":"Michael Gaber","fromEmail":"michael.gaber@gmx.net","sentAt":"2008-12-30T14:21:21Z","receivedAt":"2008-12-30T14:21:21Z","isPatch":false,"sender":{"key":"michael.gaber@gmx.net","avatar":null},"body":"Johannes Schindelin schrieb:\n> Hi,\n> \n> On Tue, 30 Dec 2008, Ping Yin wrote:\n> \n>> Yes, i know this topic has been discussed for many times.\n> \n> We have empty directory support in Git.  It works like this: for \n> directories that you do want to keep, you add an empty .gitignore file.\n> \n> No problem at all,\n> Dscho\n\nwell if i understood him correctly his use-case would soon remove that\n.whatever-file so it doesn't solve the problem\n\nMichael\n"},{"id":"98977","messageId":"46dff0320812300736x78e0086dq14fbd2c2f8f7f8c2@mail.gmail.com","threadId":"16922","inReplyTo":"200812300758.41988.robin.rosenberg.lists@dewire.com","subject":"Re: why still no empty directory support in git","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-12-30T15:36:49Z","receivedAt":"2008-12-30T15:36:49Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Tue, Dec 30, 2008 at 2:58 PM, Robin Rosenberg\n<robin.rosenberg.lists@dewire.com> wrote:\n\n> You can have an empty tree, but the index doesn't store them,\n> so they would be lost on checkout/commit. Linus sketched a solution,\n> but nobody took the bait. Seems doable if anyone really wants it, but\n> I'm certain it adds a lot of special cases.\n>\n> Look for a discussion [RFC PATCH] Re: Empty directories... posted on 2007-07-19.\n> It's in the middle of a long thread.\n>\nThanks for pointing me to that thread. For other's convenience, the\nbegin of the thread is\nhttp://article.gmane.org/gmane.comp.version-control.git/52813\n"},{"id":"99022","messageId":"20081231010620.GA26997@linode.davidb.org","threadId":"16922","inReplyTo":"alpine.DEB.2.00.0812300346040.19911@vellum.laroia.net","subject":"Re: why still no empty directory support in git","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-12-31T01:06:20Z","receivedAt":"2008-12-31T01:06:20Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Tue, Dec 30, 2008 at 03:58:46AM -0500, Asheesh Laroia wrote:\n\n> This is because git is removing these directories. There is a strict \n> incompatibility between git rmdir()ing empty directories behind my back and \n> Maildir systems.\n\nSo, would there be a hook that would run at all of the times git might\nremove the directories, and the hook could just put them back if\nmissing?\n\nThe post-merge hook is certainly one place, but there are likely\nothers.  You might also want one in post-checkout, but I'm guessing\nthat switching branches is going to be less frequent in a maildir\ndirectory.\n\nDavid\n"},{"id":"99075","messageId":"3665a1a00812311850p59f0f5e7ode1853d26c30b26@mail.gmail.com","threadId":"16922","inReplyTo":"4959BB07.6000106@gmail.com","subject":"Re: why still no empty directory support in git","fromName":"Anatol Pomozov","fromEmail":"anatol.pomozov@gmail.com","sentAt":"2009-01-01T02:50:16Z","receivedAt":"2009-01-01T02:50:16Z","isPatch":false,"sender":{"key":"anatol.pomozov@gmail.com","avatar":"https://gravatar.com/avatar/71fc20093402ce987148294ec0999d025209e52da6762789ff248cf5c317645f?d=mp&s=160"},"body":"Hi\n\nOn Mon, Dec 29, 2008 at 10:09 PM, Liu Yubao <yubao.liu@gmail.com> wrote:\n>\n> Ping Yin wrote:\n> > Yes, i know this topic has been discussed for many times. However, i\n> > am still not clear about the real reason.\n> >\n> > So which is the reason?\n> >\n> > 1. it's by design, intentional\n> It's saied somewhere git is a \"stupid content tracker\", it cares file content\n> not file name, and empty directories will complicate the merge algorithm\n> unnecessarily.\n\nCould you please explain how will it complicate merging. What is the\ndifference between merging 2 directories with 0 and 5 files and\nmerging 2 directories with 5 and 10 files?\n\n+1 that git should respect empty directories. Git should handle file\ncontent and not decide for user does he want to keep empty directory\nin the source tree or not.\n\n--\nanatol\n"},{"id":"99101","messageId":"20090101200651.GB6536@coredump.intra.peff.net","threadId":"16922","inReplyTo":"alpine.DEB.2.00.0812300346040.19911@vellum.laroia.net","subject":"Re: why still no empty directory support in git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-01T20:06:51Z","receivedAt":"2009-01-01T20:06:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 30, 2008 at 03:58:46AM -0500, Asheesh Laroia wrote:\n\n> So, let's say I take your suggestion.\n>\n> $ touch ~/Maildir/new/.exists\n> $ git add ~/Maildir/new/.exists && git commit -m \"La di da\"\n>\n> Now a spec-compliant Maildir user agent will attempt to deliver this new  \n> \"email message\" of zero bytes into the mail spool and assign it a message  \n> UID.  Doing so will remove it from Maildir/new.\n\nNo. The maildir spec says:\n\n  A unique name can be anything that doesn't contain a colon (or slash)\n  and doesn't start with a dot.\n     -- http://cr.yp.to/proto/maildir.html\n\nwhere a \"unique name\" is the filename used for a message. In practice,\nevery maildir implementation I have seen ignores files starting with a\ndot. Do you have one that doesn't?\n\n-Peff\n"},{"id":"99190","messageId":"alpine.DEB.1.00.0901021954410.30769@pacific.mpi-cbg.de","threadId":"16922","inReplyTo":"20090101200651.GB6536@coredump.intra.peff.net","subject":"Re: why still no empty directory support in git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-02T18:55:48Z","receivedAt":"2009-01-02T18:55:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 1 Jan 2009, Jeff King wrote:\n\n> On Tue, Dec 30, 2008 at 03:58:46AM -0500, Asheesh Laroia wrote:\n> \n> > So, let's say I take your suggestion.\n> >\n> > $ touch ~/Maildir/new/.exists\n> > $ git add ~/Maildir/new/.exists && git commit -m \"La di da\"\n> >\n> > Now a spec-compliant Maildir user agent will attempt to deliver this new  \n> > \"email message\" of zero bytes into the mail spool and assign it a message  \n> > UID.  Doing so will remove it from Maildir/new.\n> \n> No. The maildir spec says:\n> \n>   A unique name can be anything that doesn't contain a colon (or slash)\n>   and doesn't start with a dot.\n>      -- http://cr.yp.to/proto/maildir.html\n> \n> where a \"unique name\" is the filename used for a message. In practice,\n> every maildir implementation I have seen ignores files starting with a\n> dot. Do you have one that doesn't?\n\nFor the record, I am using Git to manage my mails, and never had any \nproblems after installing a hook which marks new empty directories with \n.gitignore.\n\nCiao,\nDscho\n"},{"id":"99203","messageId":"alpine.DEB.2.00.0901021626580.2099@rose.makesad.us","threadId":"16922","inReplyTo":"alpine.DEB.1.00.0901021954410.30769@pacific.mpi-cbg.de","subject":"Re: why still no empty directory support in git","fromName":"Asheesh Laroia","fromEmail":"asheesh@asheesh.org","sentAt":"2009-01-02T21:31:28Z","receivedAt":"2009-01-02T21:31:28Z","isPatch":false,"sender":{"key":"asheesh@asheesh.org","avatar":"https://avatars.githubusercontent.com/u/25457?v=4"},"body":"On Fri, 2 Jan 2009, Johannes Schindelin wrote:\n\n> Hi,\n\nHi\n\n*wipes the egg off his face*\n\n> On Thu, 1 Jan 2009, Jeff King wrote:\n>\n>> On Tue, Dec 30, 2008 at 03:58:46AM -0500, Asheesh Laroia wrote:\n>>\n>>> So, let's say I take your suggestion.\n>>>\n>>> $ touch ~/Maildir/new/.exists\n>>> $ git add ~/Maildir/new/.exists && git commit -m \"La di da\"\n>>>\n>>> Now a spec-compliant Maildir user agent will attempt to deliver this new\n>>> \"email message\" of zero bytes into the mail spool and assign it a message\n>>> UID.  Doing so will remove it from Maildir/new.\n>>\n>> No. The maildir spec says:\n>>\n>>   A unique name can be anything that doesn't contain a colon (or slash)\n>>   and doesn't start with a dot.\n\nOops.  I never actually tried this...\n\n> For the record, I am using Git to manage my mails, and never had any \n> problems after installing a hook which marks new empty directories with \n> .gitignore.\n\nI'll give that a shot, and my apologies for the noise on the list with \nregard to this particular example.\n\nI do still believe that git shouldn't rmdir() empty directories behind the \nuser's back, but with this particular use case gone I'm no longer as \nadamant as before.\n\nMy apologies for not having tested this earlier; I will test it shortly, \nbut there's every reason to think that Johannes and Jeff are right!\n\n-- Asheesh.\n\n-- \nIt's interesting to think that many quite distinguished people have\nbodies similar to yours.\n"},{"id":"99676","messageId":"alpine.DEB.2.00.0901072251420.9933@vellum.laroia.net","threadId":"16922","inReplyTo":"20090101200651.GB6536@coredump.intra.peff.net","subject":"Re: why still no empty directory support in git","fromName":"Asheesh Laroia","fromEmail":"asheesh@asheesh.org","sentAt":"2009-01-08T07:12:57Z","receivedAt":"2009-01-08T07:12:57Z","isPatch":false,"sender":{"key":"asheesh@asheesh.org","avatar":"https://avatars.githubusercontent.com/u/25457?v=4"},"body":"On Thu, 1 Jan 2009, Jeff King wrote:\n\n> On Tue, Dec 30, 2008 at 03:58:46AM -0500, Asheesh Laroia wrote:\n>\n>> So, let's say I take your suggestion.\n>>\n>> $ touch ~/Maildir/new/.exists\n>> $ git add ~/Maildir/new/.exists && git commit -m \"La di da\"\n>>\n>> Now a spec-compliant Maildir user agent will attempt to deliver this new\n>> \"email message\" of zero bytes into the mail spool and assign it a message\n>> UID.  Doing so will remove it from Maildir/new.\n>\n> No. The maildir spec says:\n>\n>  A unique name can be anything that doesn't contain a colon (or slash)\n>  and doesn't start with a dot.\n>     -- http://cr.yp.to/proto/maildir.html\n>\n> where a \"unique name\" is the filename used for a message. In practice,\n> every maildir implementation I have seen ignores files starting with a\n> dot. Do you have one that doesn't?\n\nMy apologies. This works just fine, and I'm a dolt.\n\nHappy new year!\n\n(I'm still academically interested in how to avoid the rmdir(), but as I \nsaid before, that's a topic for someone else to pick up now.)\n\n-- Asheesh.\n\n-- \nEnglish literature's performing flea.\n \t\t-- Sean O'Casey on P. G. Wodehouse\n"}]}