Using email between 2 developers to keep git repositories in sync

Hello there,

I have been converted to git after reading good things about it. I  
have been using it with a personal project and so I'm familiar with  
the basics.
However I need to share code with a co-developer. He also has a code  
base that I need access to. For several reasons, a shared server will  
not work so I was thinking of using email to send patches back and  
forth.
My question is related to the initial setup and sharing of our  
repositories. Would it be necessary for each of us to make a clone and  
make a tarball of that clone to send to one another before we can send  
patches? The documentation is all based on using a git or ssh server  
to set this up.

Thank you for any insights you can provide me!
Annard

Hi,

On Tue, 22 Jan 2008, ab_lists@mac.com wrote:

However I need to share code with a co-developer. He also has a code 
base that I need access to. For several reasons, a shared server will 
not work so I was thinking of using email to send patches back and 
forth.

My recommendation: Use bundles.  Just make the initial "clone" like this:

	$ git bundle create initial.bundle --all

Send the file "initial.bundle" (which you just created) to your 
co-developer.  He should now initialise his repository:

	$ mkdir my-new-workdir
	$ cd my-new-workdir
	$ git init
	$ git pull /path/to/initial.bundle master

(Someone tried to get "git clone /path/to/bundle" to work, but I don't 
know if that work was ever completed, so I assume it was not.)

Whenever he wants to send you an update, he has to do something like this:

	$ git bundle create update.bundle --all --since=2.weeks.ago

and send you the resulting file named "update.bundle".

Hth,
Dscho

Johannes Schindelin [off-list ref] writes:

On Tue, 22 Jan 2008, ab_lists@mac.com wrote:

quoted

However I need to share code with a co-developer. He also has a code 
base that I need access to. For several reasons, a shared server will 
not work so I was thinking of using email to send patches back and 
forth.

My recommendation: Use bundles.  Just make the initial "clone" like this:

	$ git bundle create initial.bundle --all

Send the file "initial.bundle" (which you just created) to your 
co-developer.  He should now initialise his repository:

	$ mkdir my-new-workdir
	$ cd my-new-workdir
	$ git init
	$ git pull /path/to/initial.bundle master

(Someone tried to get "git clone /path/to/bundle" to work, but I don't 
know if that work was ever completed, so I assume it was not.)

Whenever he wants to send you an update, he has to do something like this:

	$ git bundle create update.bundle --all --since=2.weeks.ago

and send you the resulting file named "update.bundle".

If I remember correctly either in GitFaq or GitTios at GitWIki 
(http://git.or.cz/gitwiki/), or in "Git in Nutshell" guide there
is description how to generate incremental bundle containing all
objects you created since last bundle and only those objects.

Besides, after initial setup IMHO it is much better to exchange
patches for review. Although usually there are more than two
developers in such case...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

On Jan 22, 2008 8:53 AM, Jakub Narebski [off-list ref] wrote:

Besides, after initial setup IMHO it is much better to exchange
patches for review. Although usually there are more than two
developers in such case...

Bundles allow you to maintain identical history on two or more
disconnected servers, and this is a very distinct advantage over
patches. Absent use of bundles to distribute the integrated changes,
the development history seen by both parties will diverge.

Mark

Thank you all for your feedback!

So would it be wise to synchronise the repositories over time using  
the bundles and despite having exchanged email patches or should they  
be used separately?

Thank you again!
Annard

On 22 Jan 2008, at 15:35, Mark Levedahl wrote:

On Jan 22, 2008 8:53 AM, Jakub Narebski [off-list ref] wrote:

quoted

Besides, after initial setup IMHO it is much better to exchange
patches for review. Although usually there are more than two
developers in such case...

Bundles allow you to maintain identical history on two or more
disconnected servers, and this is a very distinct advantage over
patches. Absent use of bundles to distribute the integrated changes,
the development history seen by both parties will diverge.

Mark

On Jan 22, 2008 10:05 AM,  [off-list ref] wrote:

Thank you all for your feedback!

So would it be wise to synchronise the repositories over time using
the bundles and despite having exchanged email patches or should they
be used separately?

You can use both: patches to distribute proposed changes, bundles to
distribute the integrated (and presumably controlled) branches after
changes are accepted. Of course, you can use a bundle to distribute a
proposed change as well (as a topic branch), you have to decide for
yourselves what works best. Patches are great for distributed review
over a mailing list, but if only a couple of you and no mailing list
that advantage diminishes.

Mark

On Tue, 22 Jan 2008, ab_lists@mac.com wrote:

Hello there,

I have been converted to git after reading good things about it. I have been
using it with a personal project and so I'm familiar with the basics.
However I need to share code with a co-developer. He also has a code base that
I need access to. For several reasons, a shared server will not work so I was
thinking of using email to send patches back and forth.

I think bundles or email or both is likely to be the correct solution, but 
you should know that you don't need a shared server if you each have a 
server the other can read from. Each of you sets up a public repository 
with the same basic history, and you each have local clones of your public 
repository, and you pull from the other into your local clone and 
(assuming you want to accept the other's changes) you do the merge and 
push to your own public server.

In fact, having a shared server is vaguely discouraged, since it means 
there's a repository that's no single individual's responsibility; it's 
just that it's often the case that the existing social structure is based 
on a group of co-maintainers of a single series.

	-Daniel
*This .sig left intentionally blank*

Thank you all for your suggestions! The problem is that each of us  
having a local server accessible to the other is not possible.  
Therefore I will follow the path of sending patches by email and on  
releases we can synchronise using bundles. I think that's the best fit  
for our model of developing code semi-independently.

Cheers!
Annard

On 22 Jan 2008, at 23:22, Daniel Barkalow wrote:

I think bundles or email or both is likely to be the correct  
solution, but
you should know that you don't need a shared server if you each have a
server the other can read from. Each of you sets up a public  
repository
with the same basic history, and you each have local clones of your  
public
repository, and you pull from the other into your local clone and
(assuming you want to accept the other's changes) you do the merge and
push to your own public server.

On Tue, Jan 22, 2008 at 11:52:40PM +0100, Annard Brouwer wrote:

Thank you all for your suggestions! The problem is that each of us having a 
local server accessible to the other is not possible. Therefore I will 
follow the path of sending patches by email and on releases we can 
synchronise using bundles. I think that's the best fit for our model of 
developing code semi-independently.

Is your project an open source one, or one where you don't mind the
source code being made public?  If so, another easier solution would
be to use a git hosting service, such as what is available at
http://repo.or.cz.

I'd also suggest synchronizing with bundles much more frequently than
at release points.  The problem with sending patches back and forth is
it's very easy to make a mistake, and also, as far as git is
concerned, each patch is a separate changeset applied in two places.
So it makes merging more challenging for git.  It can probably handle
it, but makes life harder for everyone concerned.  So if you can use a
site like repo.or.cz, I'd highly recommend it.

						- Ted