From: Avery Pennarun <apenwarr@gmail.com>
Date: Wed, 21 Oct 2009 19:38:27 GMT
Subject: Re: git submodules
Message-ID: <32541b130910211238s6f4a04cawd7f95c4731fe4a3b@mail.gmail.com>
In-Reply-To: <f488382f0910171015j1a6d4d9fg690867154334c514@mail.gmail.com>

On Sat, Oct 17, 2009 at 1:15 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> 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