Re: git submodule support feedback

Andy Parkins [off-list ref] writes:

On Thursday 2007, April 26, Andy Parkins wrote:

quoted

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?

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@gmail.com