Andy Parkins wrote:
Unfortunately, during development, you've switched libsubmodule1 to branch "development", but supermodule isn't tracking libsubmodule1/HEAD it's tracking libsubmodule1/master. Your supermodule commit doesn't capture a snapshot of the tree you're using.
How about if the supermodule commit errors out by default if you commit a different submodule branch than the one you committed the previous time? Require the user to explicitly acknowledge that yes, they want to check in the contents of "development" now, even though the supermodule was tracking "master" before.
Otherwise I think you could easily end up with just the opposite situation, where you forget you've checked out "development" for a moment to look at something, and end up inadvertently committing a bunch of stuff that's not ready for prime time yet. In a standalone git setting, that's no big deal since the commit only updates the current branch and doesn't touch the master branch, but (as I understand the proposal) in a supermodule setting you'd actually end up essentially doing a merge between your development branch and the previously committed master. Or maybe not a merge, but worse, you'd *replace* the previously committed master with what's in your dev branch.
I think wanting to commit a submodule on a different branch than last time is probably not a typical day-to-day use case, so we should make sure the user really wants to do it (but allow it if so.)
On a related note, it would be great from a usability point of view if there were a way to say "I always want to be on the same branch in all submodules and the supermodule." I think a common scenario will be that you are doing development that touches a couple of different applications and your development effort is really a single set of changes even though it happens to cross submodule boundaries. If this branches-in-sync option is turned on, I'd want "git checkout development" to check out the development branch in the entire set of repositories.
More generally, while I 100% agree that it's very useful to be able to operate independently on each submodule, I think it's also going to be common to use submodules to selectively clone different pieces of a larger project. Say your current development effort needs server A, library B, and documentation C, and you want to have *just* those pieces in your environment. You don't particularly care about the details of how the system has assembled the pieces you want; you want to be able to make your changes and push them when you're done. They are really just pieces of a larger code base, not independent entities that happen to be pulled together into a composite workspace temporarily.
For that use case, I don't want the system to act differently depending on whether server A and library B are in the same submodule or separate ones; I want to treat the supermodule as the repository, and the system should take care of the details of managing the submodules. When I do "git commit -a" I want it to give me one editor to write one commit comment that covers all of the changes I've made, and when I do "git checkout -b" I want a new branch to apply across all the files I'm working with.
It is entirely possible that the above is a matter best left to the porcelain layer, and that's fine with me. But I think the Perforce-style "compose a single workspace out of different bits of a larger project" model is hugely useful and whatever submodule system Git ends up with, it should be able to emulate as much of that feature as possible.
-Steve - 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