git submodule support feedback

git submodule support feedback

[Andy Parkins]

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
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git submodule support feedback

[Marco Costalba]

On 4/26/07, Andy Parkins <andyparkins@gmail.com> wrote:
> Hello,
>
>
> 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).
>

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

Re: git submodule support feedback

[Andy Parkins]

On Thursday 2007 April 26, Marco Costalba wrote:

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

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:

diff --git a/submodule b/submodule
new file mode 160000
index 0000000..f806cbe
--- /dev/null
+++ b/submodule
@@ -0,0 +1 @@
+Subproject commit f806cbe233f4568611be37213c266013b692db19

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

I'll certainly keep my eyes open.  As I say though: no worries yet.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git submodule support feedback

[David Lang]

On Thu, 26 Apr 2007, Andy Parkins wrote:

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

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

Re: git submodule support feedback

[Andy Parkins]

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?


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git submodule support feedback

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> 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?

Re: git submodule support feedback

[Andy Parkins]

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