Re: git submodule support feedback

From: Andy Parkins <andyparkins@gmail.com>
Date: Apr 26, 2007, 21:49 UTC
Message-ID: <200704262249.57238.andyparkins@gmail.com>
In-Reply-To: <7vfy6mstsd.fsf@assigned-by-dhcp.cox.net>

On Thursday 2007, April 26, Junio C Hamano wrote:

Show 8 quoted lines

> 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