Re: submodules, was Re: RFC: display dirty submodule working directory in git gui and gitk

Am 04.01.2010 19:29, schrieb Avery Pennarun:

For me one big problem comes down to producing accurate output for
'git log'.  git submodules assume that the history inside the module
is entirely separate (you need to run multiple 'git log' instances to
see the full history); git-subtree assumes that it's entirely
integrated.  In that sense, git-subtree is somewhat more in line with
the core principle of git (we track the history of "the content", not
any particular file or subdir).  Unfortunately, it also exposes a
problem with that core principle: taken to its extreme, "the content"
includes all data in the universe.  And while git could branch and
merge the universe very efficiently in about O(log n) time, 'git log'
output gets less useful about O(n) with the size of the tree.

Neither git-subtree nor git submodules seem to help with this "log
pollution" problem very much - but I don't know what to do that would
be better.

I think this depends extremely on the use case and may even differ
from submodule to submodule. It might be desirable to be able to
specify which submodule logs you want to see, because only the user
knows what is important for him. But you should be able to ask "git
log" directly without forking it in every submodule you care about,
no?

There has been a thread between Junio and Heiko about group mappings
for submodules. Maybe the configuration could be extended to contain
information about what submodule should add to the superprojects log?
http://thread.gmane.org/gmane.comp.version-control.git/130928/

Outside of this, my major problem with submodules is they use separate
work trees and repositories, and thus require lots of extra
housekeeping to get anything done.  I'd be much happier if submodules
would share the same objects/packs/.gitdir/refs/indexfile as the
superproject, and the *only* thing special about them would be that
the superproject's tree points at a commit object instead of a tree
object.  In other words, I think the actual repo format is correct
as-is, but the tools surrounding it cause a lot of confusion.

I don't care deeply where the objects live but agree about the repo
format and the confusion ;-)

Imagine if cloning a superproject also checked out the subproject
transparently,

That would be great (at least at checkout time, after clone you
might wanna decide which submodules to initialize first - unless
group mappings are working). Right now we use post-checkout hooks
to do that.

and committing dirty data inside the subproject's tree
created a new commit object for the subproject, then tacked that
commit object into the superproject's index for a later commit
(exactly as changing a subdir creates a new tree object that the
parent directory can refer to).

That would be a nice feature.

This doesn't solve some use cases, however, such as ones where people
really don't want to check out (or even fetch) the contents of some
submodules, even when they check out the superproject.  The current
implementation *does* handle that situation.  I'm not sure how many
people rely on that behaviour, though.  (And maybe the correct
solution to *that* is proper support for sparse clone/checkout
regardless of submodules.)

We do rely on this behavior. But sparse clone or group mappings
could replace that need.