On Thursday 2007, April 26, Junio C Hamano wrote: > I think older tools do not expect to find anything but tree or > blob in a tree object to begin with. Now your experimental > repository has a commit, which they do not expect to see and I > think they will be unhappy. > > If you replace the commit objects in your trees with a new type > of object 'gitlink', your older tools will have exactly the same > problem, won't they? I'm not sure, what I imagined was at the moment we have 160000 commit 0fbbf28b0eefb1546d02aabb43fa2de9b9f6d5f2 submodule The hash here is a commit hash in another repository so obviously all the git tools from older versions instantly bomb out saying they can't find that object. If, on the other hand we had 160000 blob b1819880ec7ead7354c6d1c650ea5faf9c6d629b submodule $ git-cat-file -p b1819880ec7ead7354c6d1c650ea5faf9c6d629b 0fbbf28b0eefb1546d02aabb43fa2de9b9f6d5f2 Obviously the current gitlink stuff would need rewriting to use this extra layer of indirection, but all the old tools would just see this as a blob and simply treat it as a file containing that hash. I'm kind of hoping that older versions of git would fail gracefully on a 160000 file type. If that isn't the case, then this is no solution and there'd be no point going to any effort. 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