On Tue, Feb 01, 2011 at 07:31:38PM +0100, Jakub Narebski wrote: > Dnia wtorek 1. lutego 2011 19:15, Ilari Liusvaara napisaÅ: > > > > Worse problem than the index: Tree entries. Those are actually transferable > > and IIRC older (current?) git versions don't handle empty subdirectories > > (pointing entry of type directory to empty tree hash) all too well... > > What did you mean by "don't handle" here? The following entry > > 040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty > > should be not a problem; empty tree is hardcoded and also shouldn't there > be a problem with such object. Is the problem when checking out such tree > (writing to index and/or working area)? Yes, writing to index/working area. IIRC, having such entry in tree causes a "ghost directory". I don't exactly recall what such thing broke, but I remember that it broke something (merging?)... Those ghosts also had annoying tendency to persist between commits. Commits didn't kill them. Rm didn't work. You had to create something on top/inside to get rid of them. > > Worse yet, there isn't easy way to break the tree parser to avoid current > > git versions from screwing things up (IIRC, when I tested, invalid octal > > numbers finally broke it, invalid file types didn't do the trick)... > > Well, then 1.8.0 version could be good place to break backwards > compatibility; we did similar thing when introducing submodule entries, > isn't it? Hint: Entry of mode "88888" blows up the tree parser nicely... :-) At the same time, it could be useful to have manually tracked directories (incidate via "sticky" bit of tree entry mode?) -Ilari -- 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