Subject: Re: Avery Pennarun's git-subtree?

From: Jakub Narebski <[email-masked]>
Date: Mon, 26 Jul 2010 15:13:53 +0200

On Sat, Jul 24, 2010, [email-masked] wrote:
> On Fri, Jul 23, 2010 at 6:20 PM, Avery Pennarun <[email-masked]> wrote:
>> On Fri, Jul 23, 2010 at 8:58 PM,  <[email-masked]> wrote:
>>> On Fri, Jul 23, 2010 at 3:50 PM, Avery Pennarun <[email-masked]> wrote:

>> This is indeed a problem with large repositories.  Of course,
>> splitting them with git-submodule is kind of cheating, because it just
>> makes git-status *not look* to see if those files are dirty or not.
>> If they are dirty and you forget to commit them, you'll never know
>> until someone tells you later.  It would be functionally equivalent to
>> just have git-status not look inside certain subdirs of a single
>> repository.
> 
> I think it's only cheating if you're using all of the submodules. The
> main purpose of submodules for me (although I don't currently use
> submodules) would be so I don't need to keep modules on disk that I
> don't care about. If a developer is working on an app, they don't need
> the OS directories/modules so they get much faster git status/etc and
> there wouldn't be other directories to have dirty files in. [...]

There are two issues that make submodules or git-subtree a better
solution.  If you work with subprojects via upstream subproject 
repository, and you don't always need / want all subprojects, 
git-submodule is better.  If you always have checked out all subprojects,
and you edit them in superproject, git-subtree is better.

-- 
Jakub Narebski
Poland