On 11-12-13 04:19 PM, Jens Lehmann wrote: > Am 13.12.2011 16:35, schrieb Marc Branchaud: >> I'd prefer to have floating be explicitly configured on a per-branch (or >> per-branch-glob) basis. So in addition to what Jens described yesterday [1] >> to configure an individual submodule's floating branch, I suggest there also >> be a new section in the .gitmodules file for configuring the super-repo's >> floating branches, e.g. >> >> [super] >> floaters = refs/heads/master refs/heads/dev* >> >> [submodule "Sub1"] >> path = foo/bar >> branch = maint >> url = ... >> >> [submodule "Sub2"] >> path = other/place >> url = ... > > Hmm, but you can have different .gitmodules files in different branches of > the superproject, no? Yes. I'm not sure I see that as a problem though. > Why not just have the "branch = maint" setting for > "Sub1" in the master and the dev branches .gitmodules file and drop it in > the other branches? Because I think that's an error-prone approach. If the user creates a topic branch off (an ancestor) of master, git doesn't know if the user wants floating submodules or not. If this is a bugfix topic, the user would have to edit .gitmodules to turn off floating. But that modified .gitmodules is too easily committed to the branch, and once it gets merged back into master suddenly master loses its "floating" feature. What's more, less-sophisticated users would be wary of editing an "internal" file like .gitmodules. Instead I think it's more intuitive for the repository to define which branches get floating submodules and which don't, and IMO a list of names/globs is a good way to do that. The repo's users would need to be aware of what the magic branch names are, but I think that's easily communicated in the floating-submodule scenarios I've seen posted. Git could also help by telling the user, when a branch is created or it's name is displayed, whether or not it's got floating submodules. M. -- 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