John,
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...
Regards,
Michael
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.
--
