Hi Thomas Am 18.11.2010 11:09, schrieb Thomas Rast: > The scenario is that we have a bunch of exercise questions stored in > one or several files, each living in a directory. Then, we assemble1 > those into exercise sheets (super-repos) spanning a group of questions > (submodules). That sounds like each directory is maintained by a different group of people and then there is another bunch of people choosing the content of the next exercise sheets, right? > We would like to track this in such a way that changes > to the questions propagate to other sheets (possibly in other > lectures) that use them. This could mean you would want an 'always-tip' mode for the submodules, or am I misunderstanding you here? > Training everyone in full git usage is probably not an option, so any > solution would have to have some frontend that can be explained > easily. Yup, makes sense (at least until something goes wrong, see 3). ;-) > The requirements we came up with are roughly: > > 1) commit across all sub-repos at the same time (atomicity nice but > optional) > > 1b) tag across all sub-repos "git commit" and "git tag" could be taught the "--recurse-submodule" option (but the commit part only makes sense when "git branch" can do that too, so you have something to commit on. And I think you want to enable a - yet to be implemented - file-based recursive diff and status too, to see what changes your next commit will include). And until all that materializes for submodules, a script would have to do that. > 2) do recursive clone/update of one super-repo easily That will be handled by recursive checkout and is already achieved by "git clone --recursive" (but at least in the first version both don't support an "always-tip" mode). > 3) never need to be aware of repo boundaries or manipulate sub-repo I think that this requirement is the hardest for any solution I know of or can imagine, as you hit these boundaries sooner or later either when you want to commit, push and/or when you have to resolve merge conflicts. > 4) sanely cope with branches etc. in case the user wants them A "--recurse-submodules" option to "git-branch" might be what you want here, but as this isn't there yet a script will have to do that for now. > A sample workflow might be: > > foo clone git@xxxxxxxxxxx/some/super/repo > # time passes > cd repo > foo update > # work > foo status > foo diff > foo commit -m 'one message fits all' > # possibly, but this could also be commit --no-push instead > foo push > > Merges are expected to be rare but would happen every so often. > > It seems repo can do (2) and (4) but violates (3) [requires use of > git-commit and others in the sub-repo]. git-subtree can do (1) and > (2) but probably violates (3) [need to rebase changes to sub-repo > branch] and (4). Submodules can do (2) and (4) but violate (3) and > currently have no support for (1). I think svn externals could do > (1)-(3) but violate (4) and probably (1b). > > Has this been done before? Or do we need to hack up a new wrapper > around submodules? If you would base that on submodule functionality, you would have to hack up a wrapper script for the foreseeable future because the "fully integrated" world view you seem to need is not worked on yet (and I didn't see anyone coming forward to do that). I took a cursory glance at "gitslave" Seth mentioned, it might do what you want, but I can't tell for sure as I never used it myself. Jens -- 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