GitHub announced a new redundancy-based technology built on core git version control techniques for a more reliable, highly available and performance oriented storage to repositories – DGit. While git is distributed by design (any copy of a repository contains the entire history), it doesn’t support mirroring by itself. DGit stores the data of each repo in 3 different servers. Continue reading DGit: GitHub’s distributed, sw-defined storage
Though most Linux devs may prefer git from the command-line, it doesn’t hurt to try a client with a beautiful GUI. GitKraken might be the client you always wanted to check out. Continue reading GitKraken: the missing Git client
There are several ways to communicate for serious development. It starts from mailing and ends in strong support forums. Arguably the most convenient way to communicate and close stuff in real-time would be messaging. IRC is a well-known solution for the same. But not everyone is IRC-savvy. Continue reading Gitter: chat for GitHub
You have a server and you want to rollback the directory with your website files anytime you want. You can keep a backup of the files on a separate media and copy them back. What if you made some changes to the theme and want to keep both the original version and the modified one? Redundancy increases and it’s too difficult to trackback. Continue reading gitfs: version controlled filesystem
I was about to branch a subdirectory within one of my GitHub projects as a new project. I realized that I’ll lose all revision history which I wanted to avoid for obvious reasons. I found a discussion thread on Stack Overflow to achieve this. Here’s the simplified procedure with explanation for each step. Continue reading Move subdirectory to new git repo (preserve history)
So far you could import your Git repositories to Canonical’s Launchpad code hosting service a Bazaar branch. But with the growing popularity of Git Launchpad couldn’t shy away from native Git support for long, could it? Continue reading HowTo: Launchpad’s Git repos
GitSavvy is a plugin for Sublime Text 3. It integrates some of the Git features into the popular editor and let users use those without switching to the cmdline or other GUI based Git clients. Continue reading GitSavvy: Git from Sublime Text
Having relevant information in the bash prompt or vim status bar can always help devs. Looking for options, we came across four. There prompts and bars are in general called powerlines. Take your pick! Continue reading Power prompts and vim status bars for devs
GitHub gists are a good way to write quick notes or code snippets or configurations and share those with others. There are a few cmdline clients mentioned officially but they are either unmaintained or lacking in features or need ruby. Today we came across a new client being actively developed in Python – gist.
The author is actively working on gist edit and it currently works with the user’s default editor. In addition the gist create command (without any argument) opens up the default editor to create a new gist on the fly.
To install the gist client on Ubuntu, run the following:
$ sudo apt-get install python-setuptools $ git clone https://github.com/jdowner/gist.git $ cd gist $ sudo make install
It supports TAB-completion. To enable it, add the following line in your ~/.bashrc:
source /usr/share/gist/gist.bash
You need to generate a personal access token from your GitHub settings -> Applications page and add it to ~/.gist in the form:
[gist] token: <enter token here>
Options
gist list : prints a list of your gists gist info : prints detailed information about a gist gist files : prints a list of the files in a gist gist delete : deletes a gist from github gist archive : downloads a gist and creates a tarball gist content : prints the content of the gist to stdout gist create : creates a new gist gist clone : clones a gist
There are multiple ways to create a gist from different sources.
$ git create "gist_new" foo.txt bar.txt
$ xclip -o | gist create "gist_clip"
$ echo $(cat) | gist create "gist_quick"
Webpage: gist
In a collaborative development environment sometimes it becomes difficult to find out in which commit (or check-in) a particular issue was introduced. git bisect is one way to find out the faulty commit. This is an in-built functionality of the version control system git. The procedure is quite familiar among Linux kernel devs. Note that svn has a similar option named svn-bisect.
The working principle of git bisect is simple – it’s like a binary search on a sorted list. You tell git a (good) revision where a certain functionality worked and another (bad) revision where it doesn’t. git automatically checks out the intermediate revision for you. You test and find out if the functionality works there.
Start a git-bisect session:
$ git bisect start $ git bisect bad # Current version is bad $ git bisect good v1.1.1 # v1.1.1 was the last version tested OK
You’ll see an output like
Bisecting: 47 revisions left to test after this
The revision in the middle is then checked-out. Test it. Depending on whether the functionality works or not you mark it as good or bad. For example:
$ git bisect bad
The output should be something like
Bisecting: 23 revisions left to test after this
Keep repeating the process till you find the rogue commit. Once done, reset your branch to the revision you were (before issuing git bisect start) using:
$ git bisect reset