Re: MORE: Using git via USB for personal org dir and other data files

[Bernt Hansen <bernt@norang.ca>]

Hi Alan,

The best way to test drive all this stuff is just make some throw away
repos to play with.

$ mkdir /tmp/junk
$ cd /path/to/your/org/git/repo
$ git clone --bare . /tmp/junk/org.git
$ cd /tmp/junk
$ git clone org.git home
$ git clone org.git work

Now you have 3 repos in /tmp/junk
  work - pretends to be your repo at work
  home - pretends to be your repo at home
  org.git - your bare repo on the usb stick

Now cd work, do stuff, git commit and git push
then cd home, git pull, do more work, git commit, git push
etc.

Since these are just junk repos for experimenting you don't have to
worry about messing them up and you can just rm -rf /tmp/junk when
you're done.

Comments follow:

"Alan E. Davis" <lngndvs@gmail.com> writes:

> Regarding the synchronizing of directories on two or more machines, using a USB Stick.  Further questions after a bit of experimentation. 
>  
> I am currently keeping two workstations up to date via a USB flash drive, and have had, variously, both good and bad luck. Here are some questions:
>
> 1.  I understand the idea, finally, of using a "bare" repo on the fiash drive, at least in part.  But what will I do if the bare repo fails to merge because two versions are pushed or pulled to it from
> the two machines, of a file.  I've wasted a bit of time and now have gotten "meld" installed as the mergetool.  Still, sometimes even that doesn't work.  Today I have two flash drives in use, one that
> was working fine to update from one machine, but won't even accept a file from the other.  I have clumsily deleted the old version from the USB drive, and copied over the other version, done git rm
> <oldfile> git add <file> and git commit -a, but the file refuses to install.  I'm not going to ask this as a primary question, because I think I need to just understand the underlying idea of using a
> bare repo, and not editing it at all. 
>

You never merge on the bare repo.  You do all of the merging on your
working copies (home or work).  Then pushes to the USB stick are always
fast forward changes which just work.  If you rebase and rewrite history
you can force update on the usb stick with push -f -- just make sure you
really want to overwrite the history on the usb stick with what you have
now before you decide to do that.

>
> 2.  I have had poor luck with push.
>
> 3.  For this simple usage, is it even useful to think about branches, and if so, how should branches be used?

I use topic branches all the time.  If I want to put a branch on the sub
stick I use:

  $ git push usb my-branch

When you fetch from the usb repo it will create any new branches as
usb/my-branch.

You can also delete branches when you're done with them with

 $ git push usb :my-branch

to remove it from the usb stick repo.  To remove them from your working
directory later you can use

 $ git remote prune usb

which finds any remote branch names (usb/*) that exist in your working
directory that no longer appear on the remote (usb stick) and deletes
them from your working directory repo.

> >
> 4.  Is it wiser to fetch than to pull?  I have seen this suggested, but don't understand the use of fetch.

pull = fetch + merge (or fetch + rebase) depending on the branch setup.

I personally fetch first, and if git status stays it's a fast forward
merge then I pull.

> >
> Here is a rough idea of what I think I need to do now.  Please comment on any ommissions or problems:
>
> At home, on my primarly workstation:
> 1. cd to a directory with a good tree (perhaps ~/org) already under git control.
> 2. insert the USB drive (I have a label "BLUE" on my usb drive.  On my gnome/ubuntu box, it automounts as /media/BLUE)
> 3. git clone --bare . /media/BLUE/org.git

This creates the repo with all of your branches in this working directory.

>
> 4. git remote add BLUE /media/BLUE/org.git
> 5. ??  git push BLUE (master?)

You don't need this after the clone - the new clone on the usb drive is
up to date - it doesn't hurt though :)

> >
> Now at work, I am on the other workstation:
> 1. git clone /media/BLUE/org.git
> 2. can I now do this?: git remote add BLUE /media/BLUE/org.git

After you clone the repo in step 1 the remote is added automatically
with the name 'origin'.  This would add a second remote (at the same
location) but with a different name (BLUE).  You really don't need to do
this -- you can just use the remote 'origin' but again it doesn't hurt
anything.

>
> 2. work
> 3. git push BLUE ???

That pushes any new commits on master back to your BLUE remote.  The
push will fail if the update is not a fast forward.  (ie if you added
stuff to the usb stick from somewhere else since you fetched last then
the push will fail).  In that case you need to fetch + merge first (git
pull) and resolve any conflicts you might have.

> 4.
>
> Back at home
> 1. git fetch BLUE ??  or git pull BLUE ??
>

I would just do git pull (which is fetch + merge)

If you fetch only you'll have this:

o--o--H (tip master on home)
       \
        o--o--W (time of usb/master with new commits from work)

and after a fetch you can easily see this in gitk

$ git gitk master origin/master  (or if you don't have tons of branches
                                  just gitk --all)

If you pull it will advance H (your master on the home repo) so it is at
W.  This is normally what you want to do.

>
> I am confused at a couple of points here. 
>
> Much of the above I have gleaned from three posts by Bernt Hansen.  Other sources on line include some postings on the very problem of syncing machines using git. 
>
> Can I pull from /media/BLUE/org.git ?

Yes you can (and for this setup I would recommend that as your normal
mode of operation).

AT work:
  $ git pull BLUE                                   [*1*]
  <hack> <hack> <hack> <commit> <commit> <commit>
  $ git push BLUE
  <pull usb stick and go home>
At home:
  <plug in usb stick>
  $ git pull BLUE
  <hack> <hack> <hack> <commit> <commit> <commit>
  $ git push BLUE
  <pull usb stick and go to work>
  <go to step [*1*]>

>
> Well, perhaps this is enough confusion for now.  Thanks for all the suggestions on this list.  I think it's going to work, and I'll expand this to other directories as well.

As I said up front - just play with it in /tmp until you're
comfortable.

Regards,
Bernt