Dnia czwartek 3. lutego 2011 00:33, David Aguilar napisał: > On Feb 2, 2011, at 3:23 PM, Jay Soffian <jaysoffian@xxxxxxxxx> wrote: >> On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski <jnareb@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html