DGit: GitHub’s distributed, sw-defined storage

DGit

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

gitfs: version controlled filesystem

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

Move subdirectory to new git repo (preserve history)

git_logo_compI 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)

gist: manage GitHub gists

git_logo_compGitHub 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.

Features

  • Print a list of your gists
  • Print detailed information about a gist
  • Print a list of the files in a gist
  • Delete a gist from github
  • Download a gist and creates a tarball
  • Print the content of the gist to stdout
  • Create a new gist (as private or public)
  • Clone a 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.

Installation

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

Usage

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.

  • Create from a set of files
    $ git create "gist_new" foo.txt bar.txt
  • Create from clipboard data
    $ xclip -o | gist create "gist_clip"
  • From some on the fly notes
    $ echo $(cat) | gist create "gist_quick"

Webpage: gist

git bisect: find a rogue commit

git_logo_compIn 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.

Commands

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