Re: Tips for different workflows/use cases

[Dmitry Potapov <dpotapov@gmail.com>]

On Sun, Feb 03, 2008 at 04:08:07PM +0100, Guilhem Bonnefille wrote:
> So, what is the best practices:
> - should he decide to push/pull every time from the same repo or
> should he only use the "pull" command on each repo (and never push)

If both computers are always online and you can connect at will then
"pull" is the simplest solution. The problem with "push" is that pushing
to the local branch of another that has the working directory attached
to it will give you not exactly what you want. The default refspec for
"push" is only suitable for pushing into a "bare" repository from where
anyone can pull. However, if you do not want to have a separate bare
repository for synchronization, you can avoid by providing suitable
refspec for push.

Let's suppose that you have two computers (computer1 and computer2),
and you can use computer1 to connect to computer2, but computer2 cannot
access to computer1.

In repository on computer1:

  git remote add computer2 $COMPUTER2_URL
  git config remote.computer2.push "+refs/heads/*:refs/remotes/computer1/*"

Please, note I used 'computer1' in the refspec above. It is the prefix
for local branches that will be added when they appear in the repository
on computer2. If you have only two computers then you can use 'origin'
instead of both 'computer1' and 'computer2' above, which will alow you
to use push and pull without additional arguments.

Now, you can safely push my changes from the current computer (computer1)
to computer2:

  git push computer2

Then when you start working on computer2, you can either merge changes:

  git merge computer1/master

or if you want to have linear history then you have to use rebase your
local changes on top of computer1

  git rebase computer1/master

Note: You should never rebase changes that you published (i.e. that you
share with other peoples), because rebase re-writes history.  Also, if
the first thing that you do when you change the computer is to merge
changes for another then you do not need ever use rebase and you still
will have linear history.

Now, you back on computer1, and again you can either merge changes:

 git pull computer2

or rebase local changes

 git pull --rebase computer2

Note:
 'git pull' is equivalent 'git fetch' and 'git merge'
 'git pull --rebase' is equivalent 'git fetch' and 'git rebase'


> - should he decide to create a third repo and use it as central repo.

Often it makes sense to create an extra repo. After all, disk space
is cheap and having extra backup never hurts.

> 
> 2- It's a variation of the previous one. Now, one of the two computers
> is a laptop. Is there any recommended practices to work with laptop?

I suppose that laptop computer has limited online time. So, you have to
push from it. You can push easier to a central "bare" repo, or directly
to your other computer as I described above (laptop=computer1 and
server=computer2).

> 
> 3- Now, the two computer are not connected via network. Two possible
> solutions to sync our both computers: USB disk and e-mail.
> Any recommendation in this context?

Sending patches by emails is good to exchange ideas or to contribute to
mainstream, but you cannot synchronize repositories in this way. If
you really want to synchronize by emails, you should send bundles (man
git-bundle). Bundles can be transfered by emails or using any other
media. Alternatively, you can have a copy of your repository on a USB
disk and synchronize with it using "pull" and "push" commands. However,
if you use a USB disk with VFAT, you should mount it with 'shortname='
'mixed' or 'winnt' on Linux.


Dmitry