An explanation of how I would do collaboration with git as a backend comes here.
The main idea is that people will have lots of documents, furthermore,
it should be easy to copy the entire tree. Lastly, having the same tree for all the documents can do everybody good if TeX documents needs to use the same bib, or whatever.
A few key-points here is:
- Each document has its own repository (which could be remote placement
in bare repos)
- Each document knows in principle nothing about it being a submodule.
- The main repos is a container, you can add any general thing here, like templates for new documents, template logos, etc.
- Within the main the submodules are placed. Each of these is a self contained repository with its own, independent, history, etc.
- The main repos does not track anything in the submodules, rather it tracks a commit-id of the submodule. Hence, this abstracts the version in the main repos somewhat, but here, the main repos is more a container than a tracker. Remember that the main tracks a commit in the submodules, and does not at will update the submodule. Thus to retrieve the latest in each document you should do:
- Go into the submodule and do a pull/update
- If this update should be put forth in the main repo you have to commit this in the main.
Ok, so I hope the above gave a brief explanation of what submodules are and do.
Think of the main repo as a program, and each document as a library that is used in the program. By tracking the library one can update with out problems, and easily back-track to a working version if applicable.
See this submodule link for a more general explanation.
The main point is that once you have created a main repository which contains all the documents for your group, then you can tell your employees/co-workers to fetch that one, instead of doing, fetch this, and this, and this, and ....
Also, if you are ever to do collaboration with somebody whom you do not want to share everything with, simply only give him the document repos, and not the main. You will still be able to do collaboration etc.
Ok, so I created a small bash script for you guys to play with:
#!/bin/bash
# Script for creating a couple of examples of submodule
function crt_rep {
rm -rf $1 ; mkdir $1
pushd $1 ; git init
echo "Init" > test ; git add test ; git commit -a -m "Initial, created repo $1"
popd
}
crt_rep doc1
crt_rep doc2
# Ok, so now we have two repos...
# We create a last repo which is our parent repo
crt_rep all
# Save the current path (submodules needs full paths...)
tmp_path=$(pwd)
# Go into all and add the submodules
pushd all
# Add the submodules
git submodule add $tmp_path/doc1 doc1
git submodule add $tmp_path/doc2 doc2
# Do a status
git status
# The submodules are NOT fetched!
# This will do that (I have done it explicitly)
git submodule init doc1
git submodule update doc1
git submodule init doc2
git submodule update doc2
# Add the submodules to the repos
git commit -a -m "Added doc1 and doc2 to the repo"
# Get out
popd
# An example of tracking commits, not latest. we go into one submodule and do:
pushd doc1
echo "Second commit" > second
git add second
git commit -a -m "Added second commit"
popd
# Checkout the newest document
pushd all/doc1
git pull
popd
pushd all
git status # here, you will see that "main" has uncommitted edits (the doc1 is updated to a new commit)
popd
# Remove if the collaborator already existed
rm -rf collaborator
# We clone everything (notice here that the COMMITED version in all is the one that
# is pulled)
git clone --recursive $tmp_path/all collaborator
# Or if, git -v < 1.6.5
#git clone $tmp_path/all collaborator
#git submodule update --init
Please go through it to see what it does.
As Brent put forth, I think you do way too many rebase statements. In my opinion, they are mostly useful for separating many branches (which I think is very overkill in this situation). All edits in the repo should be added directly in the main, if you want it to be temporary, simply name the file temporary (git tracks content, not names, so history search should be no problem here).
submodulefeature which allows much more grouping, and actually makes co-peers retain the same structure for all documents. The main group can then track ALL documents while each sub-document can be tracked individually. This makes setup of reps alot easier for new users (as there is one rep, which links to all the others). Then your workflow can be applied in each of the individual documents. – nickpapior Mar 19 '13 at 13:55