Rosipov

Programming

Use vimdiff as git mergetool

June 13, 2013 – 6:18 pm

Using vimdiff as git mergetool can be pretty confusing. Multiple windows, little explanation. This is a short tutorial to explain basic usage, what do LOCAL, BASE and REMOTE keywords mean. This implies that you have at least very little basic vim knowledge (how to move, save and switch between split windows), if you don’t – there’s a short article for you: Using vim for writing code. Some basic understanding of git and branching is required as well, obviously.

Git config

Prior to doing anything, you need to know how to set vimdiff as a git mergetool. Do:

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

git config merge.tool vimdiff

git config merge.conflictstyle diff3

git config mergetool.prompt false

This will set git as default merge tool, will display a common ancestor while merging and will disable the prompt to open the vimdiff.

Creating merge conflict

Let’s create a test situation. You are free to skip this part or you can work along with the tutorial.

mkdir zoo
cd zoo
git init
vi animals.txt

mkdir zoo

cd zoo

git init

vi animals.txt

Let’s add some animals:

cat
dog
octopus
octocat

cat

dog

octopus

octocat

Save the file.

git add animals.txt
git commit -m "Initial commit"
git branch octodog
git checkout octodog
vi animals.txt  # let's change octopus to octodog
git add animals.txt
git commit -m "Replace octopus with an octodog"
git checkout master
vi animals.txt  # let's change octopus to octoman
git add animals.txt
git commit -m "Replace octopus with an octoman"
git merge octodog  # merge octodog into master

git add animals.txt

git commit -m "Initial commit"

git branch octodog

git checkout octodog

vi animals.txt # let's change octopus to octodog

git add animals.txt

git commit -m "Replace octopus with an octodog"

git checkout master

vi animals.txt # let's change octopus to octoman

git add animals.txt

git commit -m "Replace octopus with an octoman"

git merge octodog # merge octodog into master

That’s where we get a merge error:

Auto-merging animals.txt
CONFLICT (content): Merge conflict in animals.txt
Automatic merge failed; fix conflicts and then commit the result.

Auto-merging animals.txt

CONFLICT (content): Merge conflict in animals.txt

Automatic merge failed; fix conflicts and then commit the result.

Resolving merge conflict with vimdiff

Let’s resolve the conflict:

git mergetool

1	git mergetool

This looks terrifying at first, but let me explain what is going on.

From left to right, top to the bottom:

LOCAL — this is file from the current branch
BASE — common ancestor, how file looked before both changes
REMOTE — file you are merging into your branch
MERGED — merge result, this is what gets saved in the repo

Let’s assume that we want to keep the “octodog” change (from REMOTE). For that, move to the MERGED file (Ctrl + w, j), move your cursor to a merge conflict area and do:

:diffget RE

1	:diffget RE

Which gets the corresponding change from the REMOTE and puts it in MERGED file. You can also do

:diffg RE  " get from REMOTE
:diffg BA  " get from BASE
:diffg LO  " get from LOCAL

:diffg RE " get from REMOTE

:diffg BA " get from BASE

:diffg LO " get from LOCAL

Save the file, quit (fast way to write and quit multiple files – :wqa).

Run git commit and you are all set!

Tags git, vim, vimdiff | Permalink | Comment (0)

Programming

Git pretty log output

June 13, 2013 – 5:31 pm

This alias has been around the web for quite a while, but it does look fantastic indeed (don’t have a lot of branching in personal repositories, but branching graphs are beautiful).

To have alias git pretty-log, execute following command:

git config alias.pretty-log 'log --graph --pretty=format:\"%Cred%h%Creset \
-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\" \
--abbrev-commit --date=relative'

git config alias.pretty-log 'log --graph --pretty=format:\"%Cred%h%Creset \

-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\" \

--abbrev-commit --date=relative'

Tags git | Permalink | Comment (0)

Programming

Download gists from prompt

May 17, 2013 – 10:52 am

Wrote a little script to download gists from command prompt.

Generate your Github API Token under Settings -> Applications, change it within a script, then do:

chmod +x shgist.py
mv shgist.py ~/bin/shgist

1 2	chmod +x shgist.py mv shgist.py ~/bin/shgist

Where ~/bin is a directory in your path. Now you can use it as shgist file to quickly download your gists (Gist on Github).

#!/usr/bin/env python

# Ruslan Osipov <ruslan@rosipov.com>
# Usage: shgist keywords
# Description: Gists downloader


import urllib
import urllib2
import sys
import json

token = 'Personal API Access Token'  # Github Settings -> Applications


class Gist:
    def __init__(self, token):
        """
        token -- str, github token
        """
        self.token = token
        self.url = 'https://api.github.com'

    def find_by_name(self, keywords):
        """
        keywords -- list of strings
        """
        gists, urls = self._get_gists()
        for i, gist in enumerate(gists):
            for keyword in keywords:
                if keyword not in gist:
                    del gists[i]
                    del urls[i]
                    break
        if len(gists) == 0:
            print "Sorry, no gists matching your description"
            return
        if len(gists) == 1:
            self._download_gist(gists[0], urls[0])
            return
        for i, gist in enumerate(gists):
            print i, gist
        while True:
            num = raw_input("Gist number, 'q' to quit: ")
            if num == 'q':
                print "Quiting..."
                return
            try:
                num = int(num)
                if 0 <= num < len(gists):
                    break
                print "Number should be within specified range"
            except:
                print "Only integers or 'q' are allowed"
        self._download_gist(gists[num], urls[num])

    def _download_gist(self, name, url):
        """
        name -- str, filename
        url -- str, raw gist url
        """
        print "Downloading %s..." % name
        gist = self._send_get_request(url)
        open(name, 'wb').write(gist)

    def _get_gists(self):
        """
        Returns 2 lists which should be treated as ordered dict
        """
        url = '/gists'
        response = self._send_get_request(self.url + url)
        response = json.loads(response)
        gists, urls = [], []
        for gist in response:
            for name, meta in gist['files'].items():
                gists.append(name)
                urls.append(meta['raw_url'])
        return gists, urls

    def _send_get_request(self, url):
        """
        url -- str
        """
        headers = {
                'Authorization': 'token ' + self.token
                }
        request = urllib2.Request(url, headers=headers)
        response = urllib2.urlopen(request)
        return response.read()

argv = sys.argv[1:]
if not len(argv):
    print "Usage: shgist keywords"
    sys.exit(0)

gist = Gist(token)
gist.find_by_name(argv)

#!/usr/bin/env python

# Ruslan Osipov <[email protected]>

# Usage: shgist keywords

# Description: Gists downloader

import urllib

import urllib2

import sys

import json

token = 'Personal API Access Token' # Github Settings -> Applications

class Gist:

def __init__(self, token):

"""

token -- str, github token

"""

self.token = token

self.url = 'https://api.github.com'

def find_by_name(self, keywords):

"""

keywords -- list of strings

"""

gists, urls = self._get_gists()

for i, gist in enumerate(gists):

for keyword in keywords:

if keyword not in gist:

del gists[i]

del urls[i]

break

if len(gists) == 0:

print "Sorry, no gists matching your description"

return

if len(gists) == 1:

self._download_gist(gists[0], urls[0])

return

for i, gist in enumerate(gists):

print i, gist

while True:

num = raw_input("Gist number, 'q' to quit: ")

if num == 'q':

print "Quiting..."

return

try:

num = int(num)

if 0 <= num < len(gists):

break

print "Number should be within specified range"

except:

print "Only integers or 'q' are allowed"

self._download_gist(gists[num], urls[num])

def _download_gist(self, name, url):

"""

name -- str, filename

url -- str, raw gist url

"""

print "Downloading %s..." % name

gist = self._send_get_request(url)

open(name, 'wb').write(gist)

def _get_gists(self):

"""

Returns 2 lists which should be treated as ordered dict

"""

url = '/gists'

response = self._send_get_request(self.url + url)

response = json.loads(response)

gists, urls = [], []

for gist in response:

for name, meta in gist['files'].items():

gists.append(name)

urls.append(meta['raw_url'])

return gists, urls

def _send_get_request(self, url):

"""

url -- str

"""

headers = {

'Authorization': 'token ' + self.token

}

request = urllib2.Request(url, headers=headers)

response = urllib2.urlopen(request)

return response.read()

argv = sys.argv[1:]

if not len(argv):

print "Usage: shgist keywords"

sys.exit(0)

gist = Gist(token)

gist.find_by_name(argv)

Tags gist, github, python | Permalink | Comment (0)

Random notes

My most used bash commands

April 24, 2013 – 12:47 pm

Shell history can tell a lot about it’s owner. What’s in your shell?

history | awk '{CMD[$2]++;count++;}
END { for (a in CMD)print CMD[a] " " CMD[a]/count*100 "% " a;}' \
| grep -v "./" | column -c3 -s " " -t | sort -nr | nl |  head -n10

history | awk '{CMD[$2]++;count++;}

END { for (a in CMD)print CMD[a] " " CMD[a]/count*100 "% " a;}' \

Here’s my office cygwin prompt, with comments:

     1  580  38.0328%    git         # I keep everything under VCS
     2  202  13.2459%    cd          # Moving around a lot
     3  171  11.2131%    vi          # Favorite text editor
     4  127  8.32787%    ls          # I'm a curious person
     5  43   2.81967%    rm          # I also like when it's clean
     6  26   1.70492%    usrswitch   # https://gist.github.com/ruslanosipov/5453510
     7  25   1.63934%    exit        # I don't like hitting the red cross button
     8  18   1.18033%    source      # Reloading bash configuration files
     9  17   1.11475%    clear       # Like when it's *really* clean
    10  15   0.983607%   gitk        # Sometimes it is too messy for git log

1 580 38.0328% git # I keep everything under VCS

2 202 13.2459% cd # Moving around a lot

3 171 11.2131% vi # Favorite text editor

4 127 8.32787% ls # I'm a curious person

5 43 2.81967% rm # I also like when it's clean

6 26 1.70492% usrswitch # https://gist.github.com/ruslanosipov/5453510

7 25 1.63934% exit # I don't like hitting the red cross button

8 18 1.18033% source # Reloading bash configuration files

9 17 1.11475% clear # Like when it's *really* clean

10 15 0.983607% gitk # Sometimes it is too messy for git log

Tags bash | Permalink | Comment (0)

Random notes

Colorless week results

April 17, 2013 – 2:32 pm

Round-up of The Week Without Colorful Prompt.

I worked with colors disabled in bash, git and vim for a week – so how did it go? It is definitely an interesting experience, but such a harsh change doesn’t really work out with everything.

Bash

Disabling colorful PS1 and removing color output for ls commands forced me to concentrate more on the actual text, changing the perception of general bash workflow. I was more concentrated on the task, missed less details and generally paid more attention to the output.

Git

Never repeat my mistake by disabling colors for git diff… Log and status are fairly easy to read, even though it noticeably slows down the workflow.

Vim

Vim without code highlight forces you to remember your code structure better, which is a great thing – without need to rely on color hints programmer has better understanding of the code he/she is writing.

Now, after experiment is over I mainly returned to using colorful prompt. But I do turn syntax highlight off once in a while – it allows you to see problem from new angle and be more efficient at finding a solution – try it!

Tags bash, git, vim | Permalink | Comment (0)

Random notes

A week without colorful prompt

April 1, 2013 – 2:10 pm

I noticed that I rely on colors in bash terminal a lot: git output, diffs, directory and file listings… It gets worse when using vim: I feel lost without cozy syntax highlight guidance.

Time to stop using output colors for a week: shell, git, vim – only plain text, no fancy colors. git config --global ui.color off, no --color flags in shell and syntax off with simple color scheme for vim.

What can I gain from it? This will definitely reduce my productivity for a few days, however I have a hint of idea that changing visual code representation will give me new insight on what I am currently writing.

Link to related commit on GutHub

Check back in a week to see how did it go!

Tags bash, git, vim | Permalink | Comment (0)

Programming

Editing bash command in vim

March 31, 2013 – 11:34 pm

You can open current command you are typing for editing in your default text editor by pressing Ctrl + x + e. It will be executed after you write and quit the file. Perfect for editing long/multi-line commands where typos are likely to occur. Consider something like this:

for run in {1..10}
do
    echo "Print me ten times"
done

for run in {1..10}

echo "Print me ten times"

done

Editing this in vim is much more satisfying, isn’t it?

You can also open last executed command for editing if you execute fc command. You can also edit last command starting with a certain pattern using fc [pattern] (you can skip the editor and execute output of fc adding -s option, useful tip is to have alias r="fc -s", which would allow you to execute last command starting with “cc” by running r cc).

P.S: In order for this trick to open vim and not any other editor, make sure you have line EDITOR=vim in your ~/.bashrc. Obviously this works with any text editor.

Tags bash, vim | Permalink | Comment (0)

Programming

Vim, pathogen and git submodules

March 27, 2013 – 1:35 pm

Step by step tutorial to organize your vim config files using git, pathogen and git submodules. This tutorial assumes that you are familiar with git basics, but you don’t really need to understand every step in order to follow it. For simplicity only .vim directory is a repository in this example. You may want to have all your dotfiles under version control and use a script to symlink files to home directory. Example: https://github.com/ruslanosipov/dotfiles

Setting up

Let’s assume your .vim directory is a mess and is not under revision control. Let’s initialize a repository.

cd ~/.vim
git init
git remote add origin git@github.com:user/project.git

cd ~/.vim

git init

git remote add origin git@github.com:user/project.git

Now let’s create .vim/bundle directory and clone pathogen plugin as a submodule.

mkdir bundle
cd bundle
git submodule add git@github.cfm:tpope/vim-pathogen.git \
bundle/vim-pathogen

mkdir bundle

cd bundle

git submodule add git@github.cfm:tpope/vim-pathogen.git \

bundle/vim-pathogen

Pre-pend following code to your ~/.vimrc to load pathogen from non-default directory:

runtime bundle/vim-pathogen/autoload/pathogen.vim
execute pathogen#infect()

1 2	runtime bundle/vim-pathogen/autoload/pathogen.vim execute pathogen#infect()

Let’s add some more plugins as git submodules, for example:

git submodule add git@github.com:Lokaltog/vim-easymotion.git \
bundle/vim-easymotion

1 2	git submodule add git@github.com:Lokaltog/vim-easymotion.git \ bundle/vim-easymotion

Now we can add and commit everything and push it to a repository.

git add .
git commit -m "Use pathogen to keep track of vim plugins"
git push origin master

git add .

git commit -m "Use pathogen to keep track of vim plugins"

git push origin master

Deploying

Assuming that your repository is located at [email protected]:user/project.git:

cd ~
git clone git@github.com:user/project.git .vim
git submodule update --init

cd ~

git clone git@github.com:user/project.git .vim

git submodule update --init

And you are done, all plugins are downloaded from their repositories now.

Maintaining

Git submodules keep track of specific commits and are not being automatically updated when target repositories have new commits. In order to update plugins you have:

cd ~/.vim
git submodule foreach git pull
git add bundle
git commit -m "Updated all the plugins in a bundle"
git push origin master

cd ~/.vim

git submodule foreach git pull

git add bundle

git commit -m "Updated all the plugins in a bundle"

git push origin master

You probably want to make sure that new versions of plugins are compatible with each other before committing though.

Tags git, vim | Permalink | Comment (0)

Random notes

IRSSI – ignore all from everyone

March 27, 2013 – 11:37 am

If you visit noisy IRC channels like programming ones on freenode, you probably want to ignore all the annoying status messages.

To permanently ignore joins, parts, quits and nickname changes from every channel in IRSSI:

/ignore * joins parts quits nicks
/save

1 2	/ignore * joins parts quits nicks /save

Keep forgetting the exact syntax, maybe clipping the snippet in a blog post will keep it in my memory.

Tags irssi | Permalink | Comment (0)

Programming

Vim movement cheatsheet

March 21, 2013 – 1:57 pm

I had this lying around for a while now, this is great vim movement commands cheat sheet made by Ted Naleid (link to an original post). It does an amazing job in helping to memorize essential vim movement shortcuts.

Tags vim | Permalink | Comment (0)

Rosipov

Use vimdiff as git mergetool

Git config

Creating merge conflict

Resolving merge conflict with vimdiff

Git pretty log output

Download gists from prompt

My most used bash commands

Colorless week results

Bash

Git

Vim

A week without colorful prompt

Editing bash command in vim

Vim, pathogen and git submodules

Setting up

Deploying

Maintaining

IRSSI – ignore all from everyone

Vim movement cheatsheet

Recent Posts

Categories

Archives

Meta

Ads