Re: Submodules or similar for exercise/exam management

From: Jens Lehmann <jens.lehmann@web.de>
Date: Nov 18, 2010, 21:20 UTC
Message-ID: <4CE5988F.7050309@web.de>
In-Reply-To: <201011181109.08345.trast@student.ethz.ch>

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). ;-)

Show 6 quoted lines

> 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.

Show 24 quoted lines

> A sample workflow might be:
> 
>   foo clone git@example.com/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