GIT Clones on Multiple Machines

Question

Here's my setup...

Laptop (Mac) - git clone of svn repository

Thumb drive - git clone of laptop git repository

Server (Win Server 08) - git clone of thumb drive repository

I'm having trouble keeping them in sync for some reason...

If I make a change on the server, I'll do a "git pull " on the thumb drive to get the changes. Take the thumb drive to the laptop and do "git pull " on the laptop. From there, I can do "git svn dcommit" and everything goes up to the SVN repo with no problem.

If I pull changes from SVN with "git svn rebase" and then do a pull onto the thumb drive and do a "git status" it says that I'm ## revisions ahead of the master/origin and I can't figure out why.

Server

>git remote show
origin 

>git remote show origin
* remote origin
  Fetch URL: E:/proj
  Push  URL: E:/proj
  HEAD branch: master
  Remote branch:
   master tracked
  Local ref configured for 'git push':
   master pushes to master (local out of date)

Laptop

>git remote show
(nothing)

>git remote show origin
fatal: 'origin' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Thumb-drive

>git remote show
origin

>git remote show origin
* remote origin
  Fetch URL: /Users/me/ui/proj
  Push  URL: /Users/me/ui/proj
  HEAD branch: (unknown)
  Remote branch:
   master tracked
  Local branch configured for 'git pull':
   master merges with remote master
  Local ref configured for 'git push':
   master pushes to master (up to date)

Answer 1

It's because the git svn rebase code rebases any commits in the repository. If any git commits you've made havent been committed to the upstream repo, the commit id will change and your other repositories will not have seen that change yet. That's my best guess right now. Your workflow is a little confusing to me. An ascii diagram might help a bit, but that'd be a little bit of work ;)

In my opinion, the best way to do this may be to git push -f ... to your thumb drive after every git svn rebase. Basically, forcibly update the thumb drive. But to be honest, I'm not much of a git guru.

Answer 2

Git commands like pull don't really work with rebases.

Let's say that on your laptop, you have some commits that aren't in svn yet, and thumb drive is in sync. Something like this:

laptop:
svn1 -- svn2 -- A -- B -- C -- D

thumb drive:
svn1 -- svn2 -- A -- B -- C -- D

Then, you do git svn rebase to get new stuff from svn. This works in two steps:

laptop (after fetching from svn)
svn1 -- svn2 -- svn3 -- svn4
          \
           + A -- B -- C -- D

Now we have to put your git work on top of new svn commits, so we still have non-branched history. This is the rebase part:

laptop (after git svn rebase)
svn1 -- svn2 -- svn3 -- svn4 -- A' -- B' -- C' -- D'

Now, if there are no conflicts, commit A' contains the same changes as old commit A, the only different thing is its ancestor: svn4 instead of svn2. Since history is a part of every commit in git, for git A and A' are different commits.

So after you do git pull from laptop repo to the thumb drive repo, git does what is natural to it, which is merge new changes:

thumb drive (after git pull)
svn1 -- svn2 -- svn3 -- svn4 -- A' -- B' -- C' -- D'
          \                                         \
           + A -- B -- C -- D -------------------- merged result

This makes complete sense in git, since it allows it to track all the changes in a non-linear environment, and note who did the merges and how. However, you won't be able to commit this kind of history to svn.

If you force-pushed the changes to your thumb repo, you'd end up with something like this:

thumb drive (after forced push)
svn1 -- svn2 -- svn3 -- svn4 -- A' -- B' -- C' -- D'

which is completely fine if you haven't done any changes on thumb drive repo. If you did, this would overwrite them. To keep thumb-drive changes, you'd have to do one more git rebase there.

I'd say that to make use of full comfort of git, you'd have to give up the ability to commit your work to svn. There's no easy way to have distributed version control and linear histories at the same time.