On Thursday 2007 July 19, Junio C Hamano wrote: > I've long time ago concluded that if we care about reliability > (and we do very much), a bisectable tree without breaking > backward compatibility is impossible. I was hoping to find a > "hole" in tree object format so that I can place an extended In the case of the notes system, is there not a big hole available because the layout is under tight control? 100644 blob 24631df5c6fceef7f0859903397d81f99a723197 __notes_index 040000 tree dd3f40129c8731b1bdce1d3939de3cdc24a87783 00 040000 tree 2b25612b5d8ee9ef469e72bbf74eab0ec00ae87f 01 In fact, this technique would work for normal tree objects too, except that you'd have to be willing to pick some blob name that would always be the first entry in every tree object, and would never clash with a real file in the tree. Speaking off the top of my head, anything with "/" in it would be an invalid name so 100644 blob 24631df5c6fceef7f0859903397d81f99a723197 /tree_index 040000 tree dd3f40129c8731b1bdce1d3939de3cdc24a87783 00 040000 tree 2b25612b5d8ee9ef469e72bbf74eab0ec00ae87f 01 Would be an easy one to special case, and would be guaranteed not to clash with a file in the tree. Just an idea. I would imagine it's as daft as all my others :-) Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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
