Git Push error: refusing to update checked out branch (Source Control)

Recently, I cloned a repository on my machine and made some changes to it. As I was pushing my changes back to the original repo, push failed with the error message:

“refusing to update checked out branch: refs/heads/master. By default, updating the current branch in a non-bare repository is denied…”

There are two things to note here in the error message. First the original repo is non-bare, secondly the push is to a branch which is currently checked out. Following are two possible ways to overcome the issue relating to bare repos and currently checked out branch.

Set Repository as ‘Bare’

Bare repositories do not have any working copy. Changes are not done directly to these repositories, rather changes are pushed from clones. Repositories hosted at GitHub are of this type.

One way to resolve the above issue is to make the repository ‘bare’. This can be done by running below command in original repo folder:

git config –bool core.bare true

Change the checked out branch

If you don’t want to convert your original repository to bare, another option is change the current branch. This can be done by:

git checkout <other_branch>

In case, there is only one branch in the repository, a temporary branch could be created and checked out:

git checkout -b temp

Once the push is executed, run the following commands to bring things back to original state:

git checkout master
git branch -d temp

Above will delete the temporary branch and checkout the master branch.

More at

Completed ‘Software Engineering for SaaS’ from Coursera

Completed ‘Software Engineering for SaaS’ course offered by Dave Patterson and Armando Fox, Professors at University of California, Berkeley. This course was offered through

The course started on 13th July and the duration was 5 weeks. Course taught the best practices for developing software as a service. It included weekly coding assignments where a SaaS application was developed using the following technologies:

Server Side: Ruby on Rails (Model: ActiveRecord, MVC View: Haml)
Client Side: HTML, CSS and AJAX
Cloud: Heroku
Software Methodology: Agile
Behavior Driven Development tool: Cucumber, Capybara
Test Driven Development tool: RSpec

Completed ‘Human Computer Interaction’ from Coursera

Completed ‘Human-Computer Interaction’ course offered by Scott Klemmer, Associate Professor of Computer Science, Stanford University. This course was offered through

The course started on 28th May and the duration was 5 weeks. It explored the design techniques and processes that help you build interfaces and technologies that bring people joy rather than frustration. Some of the contents I found similar to Mircosoft Silverlight learning site – Design toolbox. Overall it was a very good introduction to the way interfaces should be designed.


Git (Source Version Control) Tutorial from CodeSchool

Recently I started using Git and Github for one of my hobby projects. To get up to speed I went through a few tutorials. I particularly liked the one at It is an all-in-browser interactive tutorial. You just launch the tutorial link and you get command prompt, file system and connection to github all simulated inside a browser window.

Level: Very Basic
Duration: 15 minutes


Tutorial is also available from CodeSchool.


Book: Code Complete 2nd Edition

Code Complete, Book Cover

Just finished reading Code Complete 2nd edition by Steve McConnell. It is a reference book for programming best practices. Generally programming best practices books focus on requirement gathering, design, quality and management aspects of the software development process, in contract, “Code Complete” focuses on the coding or construction phase. It consists of practical insights and research data to support the practices presented in the book.  It is an excellent resource for coding standards, design guidelines and other aspects of writing code.

A big section of the books is about how to structure the code, how to indent it, how to comment it, how to name variables, how to use control structure etc. It contains code snippets in different programming languages to demonstrate the good and the bad practices. Other sections discuss the design, testing, integration, debugging and other areas.

I high recommend reading it and using it as guide for day-to-day programming activities.

Following are few important points from the book which I recollect now:

  • Code readability and maintainability are far more important then being efficient in terms of code performance or number of lines of code. The more readable the code is, the longer is the lifetime of the code. Readable code is easier to fix and enhance. It reduces the complexity of the software which is the single biggest challenge in programming.
  • Performance tuning and optimization should be performed after profiling and identification of bottlenecks, not as we write the code. Research has shown that 20% of the code runs 80% of the time. Significant performance gains can be achieved by targeting the right segment of code . Having performance tuning and optimization as one of the coding guidelines is counter productive as it affect readability and maintainability.
  • Information hiding is the key to good design. When breaking down the software into packages and classes, information hiding should be one of the guiding principles. It is important to design the packages before breaking the program down into classes. Some rules should be set to limit the inter-dependency of packages.
  • Code inspection is a very effective method of detecting bugs early. It could be even more effective than system testing. Research data shows that no single defect detection technique is able to find enough errors, more than one technique should be combined to achieve better quality. Some of the techniques are formal inspection, pair programming, unit testing, system testing, beta testing, prototyping etc.
  • Inheritance is one of the key concepts of object oriented programming, but if not used with care it also has a potential to introduce more complexity than it reduces. In the desire to model the real world, at times we introduce too many interfaces and deep inheritance hierarchies which complicate the code. When we are using inheritance, Liskov substitution principle (LSP) is a good thing to keep in mind.
  • Its good to program defensively, asserts should be used to check for pre-conditions and post-conditions of a function. Asserts are meant to check for errors which should not occur at all while exception handling should be used to handle errors which may occur at times like unavailability of network.
  • Before we start to code a function, it would help if we write the pseudo code first. Then we can put the pseudo code as comments inside function block and add actual code after each pseudo code line. This helps in coding and also saves the time required to comment the code.
  • Quality is free, it is basically a reallocation of resources. It’s free because if we don’t allocate proper resources to QA, later on we will have to incur more cost in fixing the quality issues.
  • Design is a wicked problem. Wicked problem is a problem which cannot be defined clearly until its partially or completely solved. Till the time we code the design we cannot be absolutely sure that design is correct. Moreover, coding is not just a mechanical exercise of converting design into a computer language program, instead it is a creative process. From this point of view, we should have more focus on construction phase of software project.