If you would like to make one specific Ruby be the default ruby that is selected when you open a new terminal shell, use the –default flag:
The next time you open a window Ruby 2.1.1 will be the selected ruby.
To switch back to your system ruby:
To switch at any time to the ruby you have selected as default:
To show what ruby is currently the selected default, if any, do:
If you wish to switch back to your system ruby as default, remember that RVM does not “manage” the system ruby and is “hands off”.
This means to set the “system” ruby as default, you reset RVM’s defaults as follows.
Note that “default” is merely implemented as an alias with an especially significant name.
If you encounter an error such as “RVM is not a function, selecting rubies with ‘rvm use …’ will not work.”, try using the alias action instead:
Before switching to Jekyll, I tried out Octopress, a blogging framework built on top of Jekyll…. I was really surprised to find out how much I disliked the experience with Octopress. I had an impression that it is a hacker friendly, simple and extensible blog platform, but it was the opposite of that. There are many layers of abstraction, themes are pretty complicated, it comes with many … pre-installed plugins out of the box, dozen depedencies (ruby gems), it uses Sass by default and so on. A fresh copy of Octopress blog consists of staggering 29 directories and 144 files it’s too much..!!
Octopress works almost ok if you are willing to invest plenty of time to customize it or need to build something complex, but it wasn’t my particular use case. The complexity of Octopress defeats the whole purpose of a simple, generated static site. But you know what is “hacker friendly, simple and extensible blog platform”? That’s Jekyll! Jekyll is dead simple and practical. It was a pleasure to setup and customize the default theme. It took less than an hour to have a fully customized blog just the way I wanted. So I am staying with Jekyll this time. The directory structure is really simple and you start with the bare essentials, a simple layout and a CSS file. That’s it!
I tend to prefer simplicity and unix-like philosophy when it comes to choose every day tools for specific tasks. I can always extend, build and combine on top of that, when the time comes.
you can install jekyll with a simple command :
This list isn’t complete, but the commands shown here are the handful that I use on a day-to-day basis. They should all work in a recent version of git on Linux or macOS (I don’t have access to a Windows computer anymore, but if you know something I don’t, please leave a comment and I’ll amend this article).
git log: On its own,
git logdisplays a list of commits and their commit messages in reverse chronological order (most recent commits at the top).
git log --reverse: Display the output in reverse, so the earliest commits appear at the top of the output.
git log --oneline: Passing
--onelineresults in a terse, two-column list of commit titles and SHA identifiers.
git log -p: Passing the
-pflag adds a full patch, or diff, to each commit–the code you added and removed.
git log -p <filename>: Passing a file name restricts log output to changes to that file (for example,
git log -p app/models/user.rb). You can remove the
-pflag if you don’t care about the code changes in each commit, or use
--onelineinstead to get a quick list. I find that I’m almost always interested in the actual code changes, though. If there’s a chance that git could confuse the filename for a branch name, include
--to disambiguate (
git log -p -- app/models/user.rb).
git log -p -S <query>: Use the
-Sflag (also known as the git pickaxe) along with a search term to restrict log output to code changes matching the search (for example,
git log -p -S password). Again, this will work without
-p, or with
--oneline, but this is how I typically use it.
git log -p --grep <query>: The
--grepflag searches only the commit messages for the provided query. Wrap the query in quotes if it contains spaces. (You and your team are hopefully writing useful commit messages!)
git log <commit1>..<commit2>: Restrict output to only the differences between two specific commits by passing them with a
..(and no spaces) between them. This works with SHA identifiers (
git log 660bfa2..922b5d2) as well as branch names (
git log rails-4.1..rails-4.2). Leave either side blank to imply the current branch (
git log rails-4.2..). Use with
--grepas outlined above to filter the results further.
git log --stat: Add a brief list of the files that were altered in each commit, with a count of lines that were added or removed. As you may have guessed by now,
--statcan be used alongside the other flags listed here to narrow results.
git log --no-merges: Omit merge commits from the log output (use
--mergesto show only merge commits). I don’t use these as often.
As I mentioned, this is just a list of the tools I use most often to look at the git log. If you want to learn more, Atlassian’s article on advanced git logging is a great next step.
Projectile makes your Emacs very fast…!!! after installing projectile in Emacs… It was easier to search and fin files within directories quicky projectile replaces command palette of Sublime Text Editor!
You Know … I recommend Projectile !! for more info visit :
See you next Article ..!! Tinix!
You can install the plugin using the packages on melpa.
Make sure you have something like the following in your Emacs startup file (~/.emacs.d/init.el, or ~/.emacs):
To make that take effect, either evaluate that elisp expression or restart Emacs.
Then use M-x package-list-packages, select neotree from the list by pressing i, then press x to execute the changes. At that point, the package will be installed.
Add config to emacs:
Open (toggle) NeoTree:
subscribe via RSS