Dnia wtorek 1. lutego 2011 19:15, Ilari Liusvaara napisaÅ: > On Wed, Feb 02, 2011 at 12:54:35AM +0700, Nguyen Thai Ngoc Duy wrote: > > On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > > > Could it be done with an index extension? Interesting. > > > > > Certainly one ought to register an extension name or bump the version > > > number to avoid confusing gits that don't know about the feature. > > > > Index extension with lowercase name are "necessary for correct > > operation". Older git will abort on unknown required extensions. If > > you add to the main part of the index, better bump version number. > > 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)? > 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? -- 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