Am 21.07.2010 23:09, schrieb Avery Pennarun: > What we *really* want is a way to have git actually recurse through > commit objects when doing *any* operation, as if they were tree > objects. This would not be useful for every work flow (or to put it in other words: this is not what I *really* want ;-). And as you pointed out, that only works when you have a single repo you are working against (like you do in your subtree model). But unless I got something wrong (which might very well be the case, as I never have used subtree myself), all changes to the subtree will only show up in that single repo, unless you actively push them somewhere else. And that, it seems to me, is as easy to forget as you can right now forget to push a submodules commit you already recorded and pushed in the superproject). So am I wrong assuming that subtree is more focused on a single repo containing all commits which /might/ then be shared, while submodules are about /always/ sharing code via their own repo? > There is no good solution to the submodule problem if each submodule > has to go in its own repo. I've been thinking about this for years > now, and watching lots of discussions about it on the git mailing > list, and I just can't see any other option. All the submodules have > to get pushed to and fetched from the same repo by default. Anything > else is insane. I have to object here. Your insanity is someone else's work flow ;-) And I am the last one not to admit that there are some severe usability warts still to be fixed for submodules (I put up a - not necessarily complete - list at http://wiki.github.com/jlehmann/git-submod-enhancements/ ). And myself and others are actively working on them (the next bigger thing after a new config option about when to consider a submodule modified are recursive checkouts, so that "git submodule update" will hopefully be almost obsolete in the near future). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html