Re: git submodules

["Avery Pennarun" <apenwarr@gmail.com>]

On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
>  > It's unfortunate that submodules involve a commit->tree->commit link
>  > structure.
>
> Actually it's not a big problem, you just have to "dereference" twice
>  instead of one, and be prepared to the fact that the second dereference
>  may fail (because you miss some objects). I instead believe that
>  gitlinks are a good idea.

It's actually complicated to generate the log, however.  To be 100%
accurate in creating a combined log of the supermodule and submodule,
you'd have to check *for each supermodule commit* whether there were
any changes in gitlinks.  And gitlinks might move around between
revisions, so you can't just look up a particular path in each
revision; you have to traverse the entire tree.  And you can't just
look at the start and end supermodule commits to see if the gitlinks
changed; they might have changed and then changed back, which is quite
relevant to log messages.

Probably it's more useful to just commit the git-shortlog of the
submodule whenever you update the gitlink.  It won't work with bisect,
exactly, but that's less important than generally having an idea of
what happened by reading the log.  ISTR somenoe submitted a
git-submodule patch for that already somewhere, but I've been known to
imagine things.

> Well, using the same [branch] as the supermodule is probably the less confusing
>  way. Of course, not being in the "same" branch as the supermodule would
>  clearly be a case of your tree being "dirty", and it would prevent a
>  "git checkout" to work in the very same way that git checkout doesn't
>  work if you have locally modified files.
>
>  If your submodule branching layout uses the same names as the
>  supermodule branches then yes, it's going to hurt, but I believe it to
>  be unlikely (else you would become insane just trying to remember what
>  you are doing ;p).

I think this is much more common than you think.  An easy example is
that I'm developing a new version of my application in the
supermodule's "master", but it relies on a released version of my
submodule, definitely not the experimental "master" version.  Using
your logic, the local branch of the submodule would be called master,
but wouldn't correspond at all to the remote submodule's master.

I believe such a situation would be even worse than no branch at all.
It could lead to people pushing/pulling all sorts of bad things from
the wrong places.  At least right now, people become confused and ask
for help instead of becoming confused and making a mess.

Have fun,

Avery