Re: Submodules or similar for exercise/exam management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In message <201011181109.08345.trast@xxxxxxxxxxxxxxx>, Thomas Rast writes:

    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
    2) do recursive clone/update of one super-repo easily
    3) never need to be aware of repo boundaries or manipulate sub-repo
    4) sanely cope with branches etc. in case the user wants them

This is exactly the sort of situation I wrote gitslave for.
http://gitslave.sf.net  I have a superproject of many subprojects where
I want to perform the same git operation on all of them at the same
time as if it was one giant repository (without the drawbacks of a
giant repository while losing as few as the benefits as possible).

It does not perform atomic commits across sub-repos, but otherwise
handles 1 and 1b.  2 and 4 are handled as well.  3 is mostly handled,
and by mostly, I mean if you get, for instance, a merge conflict in
the superproject or the subproject, you would need to resolve that
using the normal git commands and then typically retry the gitslave
command.  gitslave does not prevent you from using any git command in
any way you might desire, it simply allows you to use "gits" instead
of "git" when you want your command to run over all repos.

    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

In the gitslave world, this would be done:

git clone git@xxxxxxxxxxx/some/super/repo
cd repo
gits checkout master
# time passes
gits pull
# work
gits status
gits diff
gits commit -a -m 'one message fits none'
# I am not familiar with the "git commit --no-push" option
gits push

    Merges are expected to be rare but would happen every so often.

gits checkout featurebranch
# work
gits commit -a -m 'features are misunderstood'
gits checkout master
gits merge featurebranch
gits tag v1.0 -a -m "feature available"
gits push
gits push --tags

    Has this been done before?  Or do we need to hack up a new wrapper
    around submodules?

Hopefully gitslave will work for you (or could be modified to work for
you).  It is not perfect but has been working well enough for a team
of developers for over two years.

					-Seth Robertson
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]