Create a GIT sandbox server for ad-hoc work

Some months ago I was working out of the office at a client's location and I had to move my development environment there, but due to a tight and restrictive IT policy, me a some colleagues were unable to set up our current GIT repository and share our work (the proposed zip-share-meld was not tempting at all...).  The easiest solution would be to host the repository on my laptop, but then again, setting up our GIT repo in a Raspberry Pi is more fun, specially when you have a video projector available at the office, and a RetroPie running with 2 extra game controllers.

Create a fresh bare repository on the server:

git init --bare newrepo.git

Add it as a remote in our local repo:

git remote add newrepo  git://user@server.com/newrepo.git

Push all branches:

git push --all newrepo

How to fix GIT error: object file is empty (from Stack Overflow)

Source (and all credits):
Stack Overflow: how to fix git error object file is empty

This saved me from a lot of googling and trial/error, I was getting the following error:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

Maybe caused by powering off my VM sandbox while syncing or some other weirdness, normally with a very low impact as you can always do a git clone, but as I had some changes done locally on my working branch that I didn't want to miss/re-do, this saved my day. The original answer with full comments can be found at the link above, the brief version is:

cp -a .git .git-old
git fsck --full
# Remove empty files by using "rm", continue until none is left and the "missing blob" starts showing
git reflog
# It will show "fatal: bad object HEAD"
tail -n 2 .git/logs/refs/heads/master
# Identify parent of last commit (the one HEAD is pointing to), easily recognizable as it will show up twice
git show commit_parent
git update-ref HEAD commit_parent
git fsck --full
# There are some blobs left from outdated index, nuke and carry on
rm .git/index
git reset
# There should be only references to "dangling blobs", these are not errors, continue
git status
git add .
git commit -m "Recovering from lost objects"

And done.

GIT: change location of SVN URL if using git-svn

Taken from: theadmin.org, GIT wiki and wiki.kuali.org

Taken from @CommitStrip

Recently I moved my work environment to a VM sandbox, requiring to change also the location of the SVN-based repositories and server hosted locally.  As my work environment is GIT-based, I normally use git-svn to synchronize my work onto a SVN mirror, maintained mostly due to a client requirement as they still use SVN.

One would thought this would be as simple to run svn switch --relocate or just edit the .git/config file and change the svn-remote URL, but then again, this is SVN..

Just in case I backed-up the svn server and the .git/config file, then I tried the instructions below:

   Edit .git/config and change the URL in svn-remote tag  
   git svn fetch  
   Edit again the .git/config file and replace the URL with the old one.  
   git svn rebase -l  
   Change (again) the URL at .git/config file to the new one.  
   git svn rebase.  

But this yielded no result, when trying to rebase I got the following error:

Unable to determine upstream SVN information from working tree history

As explained Here this will only works if the fetch command actually fetch anything, it was not my case, so I tried the following:

   git svn info # double check UUID's  
   git config svn-remote.svn.rewriteRoot OLD_URL.  
   git config svn-remote.svn.url NEW_URL.  
   git svn fetch --parent.  
   git svn rebase.  

This did the trick, as explained below this will not break the history as the old URL will still be used in the commits, but it didn't matter to me.

Git-svn couples git commits to the origin SVN repository by embedding the original SVN url in the commit. Changing this url will change the Git commit SHA (basically rewrite all your history). Google results furnish various elaborate schemes for reconfiguring and patching up the Git repo, but the safest approach involves using built-in support for "rewriting" the Git-svn root url. This effectively tells Git to continue using the original SVN url for purposes of Git history, but use an independent URL (the new location) for actually retrieving and commit deltas (you will have to live with the old url in your commit history, but most likely you will be the only one that sees that).