threads / discuss / 21267

git submodules

Subject: git submodules

## tl;dr

4 messages between Oct 17, 2009 and Oct 21, 2009.

replies: 3people: 4as markdown or json

Steven Noonan· Oct 17, 2009, 17:15 UTC · lore

One of the open source projects I work on (CC'd) recently moved to git, but we're having some slight problems, and I believe that it's the fault of git's UI in this case.

We're using git submodules for the contributing libraries. When I commit changes to those contribs, it correctly shows in the parent repository that those folders have different revisions than what's currently committed. However, if someone pulls those changes, it doesn't automatically update the contribs to match the committed version. But doing a pull or merge _should_ update the working tree to match the committed versions. It does with file data, so why not update the submodules? Especially if the submodule revision matched the committed version -before- the pull. Why are we forced into using 'git submodule update'?

- Steven

Jakub Narebski· Oct 17, 2009, 17:27 UTC · re: Steven Noonan · lore

Re: git submodules

Steven Noonan <steven@uplinklabs.net> writes:

Show 10 quoted lines

> We're using git submodules for the contributing libraries. When I
> commit changes to those contribs, it correctly shows in the parent
> repository that those folders have different revisions than what's
> currently committed. However, if someone pulls those changes, it
> doesn't automatically update the contribs to match the committed
> version. But doing a pull or merge _should_ update the working tree to
> match the committed versions. It does with file data, so why not
> update the submodules? Especially if the submodule revision matched
> the committed version -before- the pull. Why are we forced into using
> 'git submodule update'?

Because you might want not to use most current version of submodule, so git-pull shouldn't update submodules by default. And because git-pull didn't learn --recursive option yet.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Nanako Shiraishi· Oct 17, 2009, 22:30 UTC · re: Jakub Narebski · lore

Re: git submodules

Quoting Jakub Narebski <jnareb@gmail.com>

Show 16 quoted lines

> Steven Noonan <steven@uplinklabs.net> writes:
>
>> We're using git submodules for the contributing libraries. When I
>> commit changes to those contribs, it correctly shows in the parent
>> repository that those folders have different revisions than what's
>> currently committed. However, if someone pulls those changes, it
>> doesn't automatically update the contribs to match the committed
>> version. But doing a pull or merge _should_ update the working tree to
>> match the committed versions. It does with file data, so why not
>> update the submodules? Especially if the submodule revision matched
>> the committed version -before- the pull. Why are we forced into using
>> 'git submodule update'?
>
> Because you might want not to use most current version of submodule,
> so git-pull shouldn't update submodules by default.  And because
> git-pull didn't learn --recursive option yet.

I don't think your description is correct. Steven is talking about what the command should do by default. If you checked out the current superproject, by default you should get the submodule that matches. If you don't want the most current version, you can checkout an older submodule yourself.

You may want to follow this discussion:

  http://thread.gmane.org/gmane.comp.version-control.git/130155/focus=130330

After stating that he isn't against the idea to make it automatic, Junio describes what needs to be done for it to happen and what are the corner cases that needs to be treated with care.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Avery Pennarun· Oct 21, 2009, 19:38 UTC · re: Steven Noonan · lore

Re: git submodules

On Sat, Oct 17, 2009 at 1:15 PM, Steven Noonan <steven@uplinklabs.net> wrote:

Show 10 quoted lines

> We're using git submodules for the contributing libraries. When I
> commit changes to those contribs, it correctly shows in the parent
> repository that those folders have different revisions than what's
> currently committed. However, if someone pulls those changes, it
> doesn't automatically update the contribs to match the committed
> version. But doing a pull or merge _should_ update the working tree to
> match the committed versions. It does with file data, so why not
> update the submodules? Especially if the submodule revision matched
> the committed version -before- the pull. Why are we forced into using
> 'git submodule update'?

<advertisement> git-subtree (http://github.com/apenwarr/git-subtree) is an alternative to submodules that doesn't have this problem. </advertisement>

But it probably has other problems. :) Works great for my purposes, though, and quite a few people have contacted me to say they're using it happily.

Have fun,

Avery