Re: [1.8.0] Tracking empty directories

Dnia czwartek 3. lutego 2011 00:33, David Aguilar napisał:

On Feb 2, 2011, at 3:23 PM, Jay Soffian [off-list ref] wrote:

quoted

On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski [off-list ref] wrote:

quoted

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