Re: using git for file management while writing a thesis...

["David Tweed" <david.tweed@gmail.com>]

On Thu, Apr 3, 2008 at 9:58 PM, Jordan Miller <jmil@rice.edu> wrote:
>  I am using git 1.5.3.1 on OS X 10.5.2 for file versioning for LaTeX files
[snip]
>  Everything works beautifully and incredibly speedily on my external 3.5"
> hard drive connected via Firewire.
>  On my USB keys, a huge number of changes are seen and git takes a very long
> time assessing ("deltifying") what are the changes needed (more than 10
> times the number of files are deltified!). Shouldn't git just realize that
> it only needs to make the changes that were made in the last commit, or am
>  Finally, I have also tried changing the disk formatting of the USB key to
> try to diagnose the problem. However, the problem is the same whether the
> format of the USB key is HFS+ Journaled or MS-DOS FAT32.
>
>  So, my question is what am I doing wrong with "git pull" and is there a
> better way to use git for the task at hand? Unfortunately, I have not yet
> been able to find a solution anywhere on the interwebnetblagosphere.

Not really directly relevant, but since no-one has replied: I daily
copy several revisions onto (git push) and back from (git pull) to USB
key (MS-DOS) on x86-Linux and it never takes more than a couple of
seconds. (Repo is around 17MB packed, maybe 10-400 objects updated per
push.) I know nothing about OS X, but the discrepancy between firewire
and usb suggests some performance issue in usb handling. I don't know
off the top of my head if packs on the receiveing end of a push are
mmap()'d (to find branch heads?), but OS X is said to have poor mmap
performance: maybe it interacts with usb driver to be even worse?

Anyway, only suggestion I've got is if you've got easy access to a
Linux machine with git available, try pushing from that and see if the
speed differs.

There have been reports of people using git when writing books, and I
use git to track papers I'm writing (amongst other things), so your
usage pattern is entirely normal.

HTH,
-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot