>> 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. > > At my former day-job we wrote our own "git submodule" in our > build system before gitlink was available in the core, let alone > git-submodule was a Porcelain command. > > Many developers who were new to Git found having a sea of 11 Git > repositories+working directories in a single build area difficult to > manage. They quickly found the detached HEAD feature in a submodule > to be a really handy way to know if they made changes there or not. > > Most of our developers also modified __git_ps1() in their bash > completion to use `git name-rev HEAD` to try and pick up a remote > branch name when on a detached HEAD. This slowed down their bash > prompts a little bit, but they found that "origin/foo" hint very > valuable to let them know they should start a new branch before > making changes. > > So I'm just echoing what Benjamin said above, only we did it > independently, and came to the same conclusion. > Hm. My developers are (mostly) on windows, so "altering PS1" or even writing "shell scripts" is way beyond them. They want it to "just work" (where their previous experience is SVN superprojects with multiple svn:externals). I have a hard time justifying the experience that if we're all working on master, then as soon as Joe Q developer does 'submodule update' then poof - his heads are disconnected. That said, I do also like the flexibility that having the superproject on heads/foo and a submodule on heads/bar as it allows you to integration test divergent submodule branches (indeed our CI system automatically picks them up and tries all possible combinations). -- 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
