Re: [1.8.0] Tracking empty directories

[Jakub Narebski <jnareb@gmail.com>]

Dnia czwartek 3. lutego 2011 00:33, David Aguilar napisał:
> On Feb 2, 2011, at 3:23 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> The problem with backward compatibility is twofold.  First and more
>>> important is while git supports empty tree object (it has it  
>>> hardcoded
>>> for some time, as it is necessary e.g. for initial diff, or merging
>>> unrelated branches without common ancestor), and there is no problem
>>> with entry for empty tree in a tree object
>>>
>>>  040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb  empty
>>>
>>> there is (supposedly) problem when checking out such tree (see email
>>> referenced above) with an old git.
>>>
>>> Second is that tracking empty directories would require extension  
>>> to the
>>> git index (storing trees in index, like we store submodules)... but  
>>> that
>>> is purely local matter.
>>
>> Instead of using an empty tree, construct a tree containing a single
>> sentinel file whose contents are a suitable warning not to delete/edit
>> said file using pre-1.8.0 git. Meanwhile git-1.8.0 never writes the
>> file to the filesystem. Too ugly?

Too ugly.

> I don't like where this is going. Users are not always right.  
> Touch .gitignore and be done with it.   This is a big change with  
> negligible benefits.  I don't understand why this is needed.

Two issues: first is interaction with other SCM which keep empty files
(or keep empty files when requested).  Second is skeleton of directory
structure automatically generated by some git-unaware tool.

I've never felt the need but more than 50% of Git User's Survey 2010
responders did.
-- 
Jakub Narebski
Poland