On 10-07-27 02:36 PM, Avery Pennarun wrote: > > For "recursive" commit, for my own workflow, I would rather have it work > like this: from the toplevel, I can 'git commit' any set of files, as long > as they all fall inside a particular submodule. That is, if I do > > git commit mod1/*.c mod2/*.c > > it should reject it (with a helpful message), because the commit would cross > submodule boundaries. But if I do > > git commit mod1/*.c > > I think it should create a new commit in mod1, leave my superproject > pointing at that new commit, and stop (ie. without the superproject having > committed the new commit pointer). I think that makes perfect sense. I'd also want the updated pointer to be unstaged. > Why? Because my normal workflow is: > > - make a bunch of superproject/submodule changes until they work. > - commit the submodule changes with a submodule-relevant message > - commit the superproject change with a supermodule-relevant message > > I wouldn't want to share commit messages between the two, so actually having > a single commit process be "recursive" would not do me any good. That's the workflow I'd like to follow as well. In terms of achieving this workflow with submodules and branching, what's required is that branching in the superproject takes the submodules off of the detached HEAD and onto something that won't get automatically garbage-collected in a few weeks. That could be done simply by applying the superproject's branch to all the submodules. A command like superproject/$ git branch foo origin/master would create the submodule branches on the commits identified for the submodules in the superproject's origin/master commit. To make that work smoothly I think requires all the submodules' .git directories, so the branch name can be recorded in all of them. And so I think that either "git fetch" has to recursively obtain (and update) all submodule repos, or there needs to be some kind of on-demand retrieval mechanism. Other ideas for grand-unified object stores (which I haven't been following too closely) could work as well. So with unified branching and available .git directories, I think a recursive checkout is doable and makes sense. I'd still like to control which submodules a checkout might recurse through, but I think the sparse-checkout system is the way to handle that. I also suspect that non-fast-forward submodule merges could be workable, where regular merges are performed individually in the submodules before merging in the superproject. One final, somewhat orthogonal thought: I think that "git commit submodule-dir" should require -f if the remote associated with the submodule doesn't have the commit ID you're trying to commit. > However, pushing is a separate issue entirely. Having push be recursive > would be easy, but it doesn't solve the *real* problem with pushing: git > doesn't know what branch to push to in the submodule, and the submodule most > likely isn't pointing at a pushable repo at all, even if the supermodule is. > This is why I keep coming back to the idea that I really want to push all > the submodule objects into the superproject's repo. I agree that recursive pushing doesn't make much sense, so there's no need to try to implement it. I think having "git commit" reject unpushed submodule updates in the superproject goes a long way to alleviating misordered pushing. 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