Andy Parkins <andyparkins@xxxxxxxxx> writes: > On Thursday 2007, April 26, Andy Parkins wrote: > >> I'll report further as I come across any stumbling blocks; but here > > The submodule support requires the latest version of git right? That's > going to cause trouble for people running different versions of git > (I've already experienced it in my own limited way - I had to upgrade > all the copies of git I have on my various computers before fetching > and pushing would work). If the repository contains a submodule > reference it effectively becomes inaccessible by a version of git > without submodule support. > > I think that we might be able to avoid that problem though - am I right > in thinking that the problem is that all the tools need teaching not to > follow the gitlink object because that hash doesn't exist in _this_ > tree it is a reference to a commit in another tree. > > Wouldn't it be better if the gitlink reference pointed at an object in > this tree which in turn referred to the submodule commit? That way the > old versions of git would still work with submodule objects in the > repository because they would just see submodules as pointing at a > blob. > > Have I oversimplified it in my head? 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? - 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