Archive for the ‘ Git ’ Category

IndentationError: unexpected indent

Tabs and spaces are code killers, visually and syntactically. Dealing with Python, you might see the error in the title often when sharing code with others. Focusing on VIM, people love to setup their rcfile so they get the most out of what VIM has to offer, but also makes their code easy to write and easy to read. Unfortunately, many times it’s just easy to read for them and no one else.

Python is very picky about spacing and indentation since it’s used to determine the flow of your script or program. Miss a tab or series of spaces somewhere and all the sudden you are executing code that’s not inside the if statement you just made, or you’ll get errors like above because your code just flat out fails.

When dealing with Git, and having several people committing code to a similar script or project, you are bound to run into situations where tabstops and shiftwidths are in conflict. It may look like all of the code lines up visually, but where one person uses spaces, another may have used actual tabs. Then you notice they made over 100 changes to the code you’re working on, and there’s tabs and spaces mixed all over the place. You have the following in your .vimrc:

set expandtab
set tabstop=4
set shiftwidth=4

It would be great to fix all of the tabs and spaces to be the same. Now what? VIM to the rescue! Bare with me, this is a bit complicated. Once you open the file in VIM, execute the following:

:%retab

You’re done, by the way. This uses your settings, and converts all of the tabs to the settings in your .vimrc. Now your entire file is standardized as far as your spacing goes and you can say goodbye to your unexpected indent errors. If you find yourself having to do this often, you can bind a key to automagically make the changes for you by adding this into your .vimrc (using F2 in this example):

map <F2> :retab <CR> :wq! <CR>

This will convert all of the tabs to spaces and save the file for you. Enjoy!

2010
10/26
POSTED BY
CATEGORY
Git
Python
VIM
TAGS


2 comments

Upgrading Gitorious

[2010-07-12] UPDATE: I just confirmed that this works for the latest mainline.

We use Gitorious at work as our Git front-end. We opted to not use Github since we wanted something we didn’t have to pay for, and was internal to our network. It has a great feature-set, and pretty much does everything we need it to do and more.

There is a bit of documentation on how to get Gitorious installed (as painful as it may be), but there’s little to no documentation on how to upgrade it once it’s installed. I just went through an upgrade and it turned out to be much easier than I was anticipating.

First, we need to get the latest source:

  $ cd ~
  $ mkdir ~/gitorious
  $ git clone git://gitorious.org/gitorious/mainline.git gitorious

Next, we need to go through and compare all of the configuration files.

  $ cd gitorious
  $ cd config
  $ diff <foo> /path/to/current/gitorious/install/configs/<foo>

Where foo is any specific configuration file in the new Gitorious source and your current install. I found that for the most part I was able to copy my old configs in place and not have to change anything.

This step is dependent on your install, but I made a few custom modifications to the source. I did not like how the “Projects” and “Repositories” pages were not listed alphabetically. They seemed to be ordered by descending creation date. Here’s the changes if you want to see how to do this as well:

--- app/views/projects/index.html.erb       2010-04-27 10:57:09.109711812 -0400
+++ /var/www/gitorious/app/views/projects/index.html.erb        2010-04-27 10:29:50.799722064 -0400
@@ -25,7 +25,7 @@
 <h1>Projects</h1>

 <ul class="project_list">
-<% @projects.each do |project| -%>
+<% @projects.sort_by { |p| p[:title] }.each do |project| -%>
   <li class="project_list_item">
     <%= render :partial => project, :object => project -%>
   </li>
--- app/views/projects/show.html.erb        2010-04-27 10:57:09.109711812 -0400
+++ /var/www/gitorious/app/views/projects/show.html.erb 2010-04-27 10:29:50.799722064 -0400
@@ -32,7 +32,7 @@
   <%= render_markdown(@project.description, :auto_link) -%>
 </div>

-<% @project.repositories.mainlines.each do |repo| -%>
+<% @project.repositories.mainlines.sort_by { |r| r[:name] }.each do |repo| -%>
   <%= render :partial => "repositories/overview", :locals => {:repository => repo} -%>
 <% end -%>

We also use Redmine at work for issues and project management within our team. One of the features of Redmine is the ability to browse source and do code reviews. In order to do this, Redmine needs access to the repositories. A lot of solutions out there suggest writing cronjobs to clone the source into a place Redmine can read. I found this horrible since the clone will be out-of-date quickly unless you have a cronjob which runs more frequently than your developers commit. My solution is a bit better, and allows for live-code browsing. We happen to have Redmine on the same system as Gitorious (both being Ruby on Rails, this worked out nicely). In our Redmine install, I created a symlink to the Gitorious repositories folder (you can use an NFS mount if they are hosted on different machines). That solved Redmine’s ability to have direct access to the source. The problem with that is the Gitorious naming-scheme is not human-readable. So the problem we had is how to tell Redmine which folder to look at for a specific project. We solved this by using the directory information in the Gitorious database and exposing it in a format that can be pasted into Redmine. Here’s the diff for this feature if you want to use it:

--- app/views/repositories/show.html.erb    2010-04-27 10:57:09.109711812 -0400
+++ /var/www/gitorious/app/views/repositories/show.html.erb     2010-04-27 10:29:50.809717943 -0400
@@ -63,6 +63,9 @@
       <strong><%= t("views.repos.created") %>:</strong>
       <%= @repository.created_at.to_s(:short) -%>
     </li>
+    <li>
+      <strong>Redmine: </strong>/var/www/redmine/repositories/<%= @repository.real_gitdir.to_s() -%>
+    </li>
   </ul>

   <ul class="links">

This will show up in Gitorious in the informational section on the right-hand side when viewing a repository.

Now that you have copied your configuration files over, and your personalized code changes, it’s time to put the new source in place. Backup your current install and current database before doing anything. Once that is backed up, delete the old install, and put the new one in place. Copy your repositories directory from the old install into the new one. Copy your public/system directory from your old install to the new one to migrate avatars. Then update the database (this is assuming you are using the production environment):

  $ cd /path/to/new/gitorious/install
  $ rake db:migrate RAILS_ENV=production

This shouldn’t return any errors, just a list of database changes that were made to accommodate the new install. If that is successful, you can restart your services (we use Apache, so it was just a matter of restarting Apache) and then visit your Gitorious page to make sure nothing is horribly broken. If there are any problems, it is most likely an issue with the version of Ruby, or of the gems you have installed. Review the contents of /path/to/new/gitorious/install/README for information on what versions are required and how to install them.

2010
04/27
POSTED BY
CATEGORY
Git
Ruby
TAGS



2 comments