git submodule support feedback

Hello,

I've started using submodule support in one of my projects. I was previously using my own poorman's submodule support where I kept the commit in a file, .gitmodules. Git's new submodule support is superior to this method and doesn't lose me any features over what I had so I thought I'd change.

My general comment is that it's great. I've tried to trip it up a few times, but it works exactly as one would expect. I was surprised how little I had to understand in order to make it work, I didn't even need git update-index. git-add and git-rm work fine when the directory you're adding is a git repository in itself. Lovely.

I'll report further as I come across any stumbling blocks; but here is one to get you going: (It's not a problem with git really, and the workaround is simple, I'm reporting it for your information rather than to get it fixed).

In the master branch I deleted my .gitmodules file and did
 
 $ git add submodule
 $ git commit -m "Chuck poorman's-submodule use gitman's-submodule"

This took over the submodule management beautifully. Now, I swapped to another branch and tried to merge the master branch:

 $ git checkout somebranch
 $ git merge master
 fatal: Updating 'submodule' would lose untracked files in it
 Merge with strategy recursive failed.

I appreciate why this has happened - submodule, from the point of view of git - doesn't exist in that branch, but the directory always has, as that's where I've kept it as my pseudo-submodule. The fix was to do

 $ mv submodule submodule.tmp
 $ git merge master
 $ rmdir submodule
 $ mv submodule.tmp submodule

I bring this up only because anyone who's moving from non-submodule to submodule support might run into the same problem.

In short: great stuff - this is already more facility than I had, thanks chaps.

Andy

On 4/26/07, Andy Parkins <andyparkins@gmail.com> wrote:

Hi Andy,

because submodules are a new feature I would not be surprised if some small correction is needed in qgit code to correctly handle that.

  In case you use qgit I would appreciate very much any bug report
regarding this new submodules thing.

I still didn't test submodules compatibility myself, but in case of a bug report against qgit probably I will be forced to do ;-)

Thanks Marco

On Thursday 2007 April 26, Marco Costalba wrote:

Of course; however, as of yet it's coping admirably. I think that it's mainly because submodules are, for external-to-git purposes, displayed as patches to a file.

That means that qgit is showing the initial addition of a submodule as the addition of a file (which nicely shows up green in the file list), and the patch itself as:

On Thursday 2007, April 26, Andy Parkins wrote:

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?

Andy

On Thu, 26 Apr 2007, Andy Parkins wrote:

if you need to teach your version of git to accept this object that then points to the new tree don't you have to upgrade it to a version that does this? at that pont you could just upgrade to a version that supports them the current way.

David Lang

Andy Parkins <andyparkins@gmail.com> writes:

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'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