Am 08.06.2010 09:12, schrieb Johan Herland: > - When switching branches in the superrepo, you sometimes also want to > switch branches in the submodule. This is signalled by changing the > submodules.subthing.branch variable in .gitmodules between the two branches. > However, it means that the submodule's update/pull operation must also be > done on 'checkout' in the superrepo. Hm, I always want the submodules to switch branches along with the super- project (I posted a RFC patch for that), but i can see other people don't want that at all or just for some submodules. But am I wrong assuming that it's either "switch branches in submodules too every time" or "never do that" for a single submodule? > - How to handle local/uncommitted (staged or unstaged) modifications in a > submodule when pulling or switching branches in the superrepo? The right > answer here is probably to do the same as in the no-submodule case, i.e. to > refuse if it would clobber/conflict with the local modifications. Yup. I thing one goal for submodules is that they should blend in with the superprojects as far as possible (unless configured to not to). > - When you track submodule branches instead of commits, the actual commit > referenced in the superrepo is no longer as important (provided it's part of > the ancestry of the submodule branch you're tracking). However, diff/status > will still list the submodule as changed because you checked out a different > commit from what Git has recorded. This raises two concerns: (1) What > _should_ be considered "changed" from the diff/status perspective when > tracking submodule branches? and (2) When do you update the commit reference > in the submodule? "never" would work (since you're checking out a different > commit anyway), "always" would also work (for the same reason), but would > litter the superrepo history with submodule updates. There may be a better > alternative somewhere in between. Don't record a commit in the first place, following a branch is not bound to a special commit, so pretending to do that might do more harm than good. Just putting the 0-hash there might be the solution. > - If you want to give the illusion of "one big repo" then maybe it should > also be possible to trigger submodule commits from a superrepo commit? (i.e. > having a single toplevel "git commit" also trigger commits in submodules). > Some users will want to specify the commit message for each submodule > separately (IMHO the better approach), while some will want to give only one > commit message that is reused in every submodule commit. Hm, personally I am fine with first committing in the submodules and then in the superproject. -- 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