On Mon, Jul 28, 2008 at 4:40 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > Most importantly in my case, my submodules (libraries shared between > apps) have a very different branching structure than my supermodules. > It wouldn't be particularly meaningful to force them to use the same > branch names. > > Further, if you don't have a separate .git directory for each > submodule, you can't *switch* branches on the submodule independently > of the supermodule in any obvious way. This is also useful; I might > want to test updating to the latest master of my submodule, see if it > still works with my supermodule, and if so, commit the new gitlink in > the supermodule. This is a very common workflow for me. I second this sentiment. I happen to very much *like* the fact that the coupling between submodules and their super-projects is minimal. The flexibility this allows is very useful. Of course, it brings to mind the comment Stroustrup once made about C++ blowing off your whole leg. > On the other hand, your thought about combining the "git log" messages > is quite interesting. That *is* something I'd benefit from, along > with being able to git-bisect across submodules. If I'm in the > supermodule, I want to see *all* the commits that might have changed > in my application, not just the ones in the supermodule itself. I > suspect this isn't simple at all to implement, however, as you'd have > to look inside the file tree of a given commit in order to find > whether any submodule links have changed in that commit. It's > unfortunate that submodules involve a commit->tree->commit link > structure. Let my contrariness begin... I can see how someone might find such a feature in "git log" useful, but I don't think I would. I have 3 submodules in my project right now, and I don't always want to see the changes. Most of the time, I don't care, actually. When I do care, I can search the output of "git log" for commits that touch the path where my submodule lives (through Gitk, usually), and I can open another Gitk for details. As for "git bisect": I haven't done this and I'm too busy to try to contrive something for the purposes of this email, but wouldn't it basically already do what you want? Seems that you'd just run "git submodule update" after each step of the bisect. > > > One irritating problem with submodules, is > > that when someone else commited, and that you git submodule update, > > you're on a detached head. Absolutely horrible. > > I think that roughly everyone agrees with the above statement by now. > It would also be trivial to fix it, if only we knew what "fix" means. > So far, I haven't seen any good suggestions for what branch name to > use automatically in a submodule, and believe me, I've been looking > for one :) I disagree with this completely. I think the detached head is actually fantastic because it tells you all the right things: a) the branch your submodule is on is ultimately irrelevant b) it reminds you that this is not your project. It's part of your project managed in a special way by Git, but your project is in .. c) if you want to do work in this part of your project that comes from somewhere else, you need to be thoughtful about how you manage its branches. I try to keep all my submodules on (no branch) as much as possible. In a way, I feel like that kind of relieves me of the chore of keeping mapping superproject branches to submodule branches in my head. I pretty much support submodules as they are, with the exception of wanting "git submodule update" to be executed automatically at times. -- 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
