From: Andy Parkins <hidden> Date: 2016-06-15 22:43:07
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
From: Marco Costalba <hidden> Date: 2016-06-15 22:43:07
On 4/26/07, Andy Parkins [off-list ref] 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
From: Andy Parkins <hidden> Date: 2016-06-15 22:43:07
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:
From: Andy Parkins <hidden> Date: 2016-06-15 22:43:07
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
From: David Lang <hidden> Date: 2016-06-15 22:43:07
On Thu, 26 Apr 2007, Andy Parkins wrote:
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.
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