Sounds similar to a scenario I want to consider: promote local Git branch 
to remote (SSH) bare repository. In other words, your post benefits 
community. It's helpful. Thank you...



On Friday, December 7, 2012 10:29:29 AM UTC-6, John McKown wrote:
> Idiot me. This is the same as the use of "scp -r" mentioned in the books, 
> isn't it? Just "local" instead of via "ssh". Why do these things occurred 
> to me _after_ I post?
> On Friday, December 7, 2012 10:25:41 AM UTC-6, John McKown wrote:
>> The way that I normally work is that I have a source directory for a 
>> project. I do a "git init" on it. I do the usually stuff and eventually end 
>> up with something that I want to share. I share via an NFS mount NAS device 
>> at home. So, what I do is a "cd" into the "git" subdirectory on the NAS, 
>> then do a "git init --bare --shared project.git". I then go back to the 
>> working directory and do a "git remote add origin ..." followed by a "git 
>> push --all". This has worked in the past. I'm doing something a bit weird 
>> right now. I'm making a git directory which contains files which are bzip2 
>> compressed. The files are about 140Gb uncompressed, but compress down to an 
>> amazing 80Mb! Yes, a fantastic compression. But with I tried the "git push 
>> --all", the process goes to about 60%, then dies on a SIGKILL (signal 9). 
>> Anyway, it occurred to me that perhaps it would be just as valid to simply 
>> go into the .git subdirectory of the project and do an "rsync -av" into the 
>> project.git subdirectory on the NAS. It seemed to work because after I did 
>> the rsync, I did a "cd" back to the project subdirectory and a "git push 
>> --all" and receive the "Everything up-to-date" message. Which is exactly 
>> what I was hoping for.
>> Is rsync the way that I should have been doing it from the first? It was 
>> much faster than the "git push" and it worked with no apparent problems.


Reply via email to