If you want to leave Github for whatever reason, you probably want to take all your code with you, and all your history and branches, etc. Here's an example for how I moved my Android Eclipse workspace from Github to my own remote server. First I make a new git repo on my remote server: $ git --bare init ~/git/workspace The --bare option means I'm not going to work on the code in the remote git repo directly. Next I push my current local 'master' to the new repo: $ git checkout master $ git push ssh://me@myserver.com/git/workspace master After that I push my working branch: $ git checkout work $ git push ssh://me@myserver.com/git/workspace work You could repeat this step if you have more branches. I created my local repo using 'clone' so it has an 'origin' remote branch defined. This 'remote' branch is where git fetches and pushes changes. Right now my 'fetch' and 'push' remote origins point to Github: $ git remote -v git@github.com:gdonald/workspace.git (
I recently set out to learn more about git, the new content manager for source code. "New", as in much younger than Subversion, and a hell of a lot younger than CVS! No one I know personally uses git yet, but I see the Ruby on Rails community starting to use it a bit, so I decided I had better get up to speed. I didn't really need the full power of git. I just needed a simple setup, somewhere I could commit code over SSH. The initial steps for such a setup were not exactly simple to learn as a first-time git user. Hints were scattered across many different websites. So I'm documenting everything I've learned here in a blog entry, in case other git n00bs like myself might find it useful. First make a new git repo on your remote host: mkdir -p /git/foo cd /git/foo git init git should return something like: Initialized empty Git repository in .git/ Your /git/foo path will likely be different than mine, but it doesn't really matter where you put stuff. I already had an /svn directory wi

Every day I see new Linux Kernel hackers fail at their first patch submission. I'm not an expert, but I've learned how the process works and most importantly I've learned how to avoid irritating Linux Kernel maintainers. The "maintainers" are the gate keepers to the Linux Kernel. If you piss them off you will never land any patches into the Linux Kernel. All Linux Kernel development takes place in the open and hundreds (thousands?) of Linux Kernel developers will see and possibly read your patch submissions. You will want to make every effort to submit the best possible patch you can. That's where I come in. If you follow my guide there's a better than average chance you will actually land your patch into the Linux Kernel. For a beginner I recommend working on the drivers/staging tree maintained by Greg Kroah-Hartman. Clone Greg KH's staging tree: > git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git This will take a while. After that you need to checkou

   Recent articles
How-to build latest Linux kernel from Linus' git repo on Debian/Ubuntu
Visual Studio Code Configuration
Lots of great reasons to ditch the Electoral College
ignore latin1 problem via psql
airplane (1) apache (1) apple (1) bash (2) bashrc (1) blackjack (1) callproof (1) college (1) config (1) console (1) data (1) debian (4) diff (1) django (2) electoral (1) enterprise (1) flying (1) freebsd (1) games (1) git (3) github (2) gmail (1) go-lang (3) google (1) gourse (1) kernel (3) latin1 (1) linux (4) lottery (1) microsoft (1) module (1) mongodb (1) mp3s (1) mutt (1) patch (1) photos (1) postgresql (2) powerball (1) psql (1) python (2) raspberrypi (1) rc (1) rubocopyml (1) sed (1) stack (1) sublime (1) testing (2) trace (1) ubuntu (2) utf8 (1) virus (1) visualstudiocode (1) vote (1) waylon (1)

Copyright © 2017 · GregDonald.io · All Rights Reserved