Question

This is a recurring question for me, but I’d like to reiterate.

Quickly explain my situation: I am in an environment where I don’t have a a git server, nor a shared partition or any common point among the coders. Don’t have, will not have, can not have. Period.

I’m trying to come up with a workflow solution, to even in that environment we manage keep our reps at reasonable sync.

The solution I’m trying at the moment uses a discussion group to distribute patches, two main branches and with a seemingly short workflow, follows:

• The branches are marster and yours
• master is the sync branch, which will keep you up to date and track what other deves still don’t have of your code.
• yours will be your new master, and is where your final code should be. You do not work in master.
• everybody sends patches to the discussion list.
• I’m considering that very rarely two people will work in the same file.

There are two main actions in the workflow:

Generate patches:

1. Got to yours
2. Generate patches from master (git format-patch master)
3. Go to master
4. Merge yours into master
5. > Go to yours, continue working with yours

Apply patches:

1. Go to master branch
2. Apply received patches
3. Go to yours branch
4. Merge master into yours
5. > Continue working with yours

If I got it right, this should keep a master branch reasonably in sync with everyone else.

Not that the yours branch is only to help in keeping track of what other people have or not.

There are a few problems I’m trying to figure if will be too much hassle:

• Order of patches applied?
• How to avoid and detect when someone misses a patch?
• How much problem can be when someone misses a patch?
• Other problems this can generate I haven’t even thought of?

Thanks!

Answer 1

Instead of having one repo with two branches, I would rather have two repo:

• one with only master branch in it
• one (cloned from the first) with master and yours

That way I can:

• merge what I need from yours branch to master in the ‘yours‘ repo
• fetch changes from the master branch of the yours repo into the master branch of the master repo
• Make a incremental bundle from the master repo (resulting in one file, easier to communicate)
• mail that one file, along with the SHA1 of the master repo

On the receiving end, I would:

• pull from the bundle into the master repo
• check its SHA1 (that way, I am sure I didn’t miss anything)
• pull the master branch from the master repo into the master branch of the ‘yours’ repo
• merge what I need from the master branch to the yours branch.

The idea of having two separate repo is to have one with a SHA1 which can be checked on the receiving end: it must be exactly the same in both sites.