4

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!

Community
  • 1
  • 1
filippo
  • 5,173
  • 12
  • 47
  • 68
  • 1
    i think it would be way easier to setup a git server accessible by all your team members. afaik `format-patch`/`am` will generate unique commit hashes per repository (different committer). so even if the trees in your repository are the same and history is basically the same, merging/comparing and talking about a particular commit will be a pita (because everybody has different commits, which just happen to evaluate to the same patches). save yourself the hassle and setup a server or get accounts on one of the many hosting sites (github, gitourious, etc.) — they offer private repositories too. – knittl Jul 11 '11 at 09:00
  • man.. I *know* that this would be the best. But right now, as I said, I can't (really can't) and to be honest, kind of don't want to - just for the challenge in trying to figure out a way :) – filippo Jul 11 '11 at 09:04
  • why can't you? if your project is open source you get even free accounts on the aforementioned sites (plus repo.or.cz). for brain-food: have you had a look at `git bundle`? – knittl Jul 11 '11 at 09:07
  • Environment and corporate related issues. Kind of explained in the comments here: http://stackoverflow.com/questions/6217187/keeping-repositories-in-sync-without-being-able-to-push-and-pull-commits/6217273#6217273 , And no, never used ``git bundle``, will take a look! thanks. – filippo Jul 11 '11 at 09:53

1 Answers1

2

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.

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • So, lets say we are 3 working together, we all did some work and sent our bundles to the mailling list.. Wen we come in the morning there will be two bundles for each of us. So we all do: pull from one, pull from another, all into master0. Pull from master0 into masterMine. You are saying this point, all the masterMine's (the three of then) should have same file states (thus same SHA1), regardless of the sequence we did the pulls? (ofc we wont know the final SHA1 until we are finished, but you got the point..) – filippo Jul 11 '11 at 13:59
  • @filipo: regarding the SHA1, I was talking about `master0`, not `masterMine` (which include the '`yours`' branch whose content can vary greatly). But even for the `master0` repo, ... according to this answer, no. http://stackoverflow.com/questions/5632520/apparently-same-commits-give-different-sha1-why/5632680#5632680: the parent of the commits would differ from `master0` repo to another `master0` repo. – VonC Jul 11 '11 at 15:20
  • @filipo: The "same SHA1" scheme might work with commits *applied in the same order* (which can be done with a `rebase --interactive` and a good naming convention in the comments of said commits in order to reorder what you just pulled). But this is no trivial solution. – VonC Jul 11 '11 at 15:21