On 7/28/08, Pierre Habouzit <madcoder@xxxxxxxxxx> 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 -- 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
