avp::ptr weblog

Sometimes it is useful to copy a series of commit to another branch. This post describes how to do this using git rebase. Two example illustrate different scenarios which should help to understand the command arguments in generell.

Example 1: The commit P, Q, R which are contained in branch feature should be copied to branch master. The commits should be appended to commit M.

The first command git rebase --onto M O R copies the commits P, Q, R to the branch master. They won’t be visible if you check the visual graph in gitk. This is because there is no branch reference that points to one of the three commits. To update the branch master run the second command git rebase HEAD master which moves up the HEAD to commit R.

Read the rest of this entry »

Reading todays post-hook emails with the latest diffs of some project the thought rushed to my head that it would be nice to have the diffs displayed in color. Since I am using Thunderbird as my email client I found a great add-on named “Colored Diff”.

Although, the add-on seems to be outdated to work with the latest Thunderbird version (which is 10.0 right now) there is an easy way to install the add-on while the automatic installer refuses to do so. Here is what you can do to make the installation work.

1. Download the Colored Diffs *.xpi file
2. Open the archive with an archive manager of your choice
3. Edit the contained install.rdf with a text editor of your choice
4. Change the maxVersion parameter to be equal or greater then the current version of Thunderbird
   Before: <em:maxVersion>3.1.*</em:maxVersion>
   After: <em:maxVersion>13.1.*</em:maxVersion>
5. Save the changes and store them back into the archive
6. Install the add-on

Do not forget to check out the preferences after you installed the add-on. You can choose 4 different types to display the diffs and customize the colors as well.

If you feel interested to enhance the add-on you can do so. The “Colored Diffs” project is hosted on google-code open for people to participate.

Quiet often there is the need to add files to the recent commit. This can be done with 2 simple commands.

git add file
git commit --amend

In case you do not wand to change the commit message there is the new option –no-edit for git commit introduced in git 1.7.9. The git release notes describe how the –no-edit option can be used.

“git commit –amend” learned “–no-edit” option to say that the
user is amending the tree being recorded, without updating the
commit log message.

git commit --amend --no-edit

Of course, I added an alias for the new option to my global git configuration.

ci = commit
cm = commit -m
ca = commit --amend
cn = commit --amend --no-edit

Once in a while one forgets to configure the user name and email address for git when initializing or cloning a new git repository. So do I. But git would not be git if it does not have an answer to that problem. Here is what git prints out when you commit without previously configuring the user credentials.

⚡ git cm 'Initial import.';
[master (root-commit) 0396c37] Initial import.
Committer: User User@Machine.(none);
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name ''Your Name''
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file

Well done git!

While working with a version control system like git it is sometimes a good idea to create an independent branch. This article shows how to accomplish that. In this example I want to hold onto the documentation in a separate branch.
I assume, that you already created a repository and added various commits onto you master branch.

Prepare your ignore list
Now its time to prepare for the repository. First, edit your .gitignore file and exclude the doc/ folder which you will be creating in the next step.

Create an orphan branch
Create a new independent branch with the git checkout option --orphan. The option is available since Git 1.7.2. Initially, you will have to remove the files that have been created in the working directory, but right after the branch is independent.
Now you can create a doc/ folder and create documentation files. In the end you can commit them to the repository as usual.

git checkout --orphan documentation
git rm -rf .
mkdir doc
cd doc
// Do work.
// git add your files to the doc/ folder
git commit -m "Added documentation files."

Checkout the master branch
To checkout the master branch while still being able to list the documentation files do the following.

git checkout master && git merge --no-commit documentation
git reset master

The files added to the documentation branch earlier will appear in the working directory visible to the master branch. Thanks to the .gitgnore file they will not be listed as untracked files.

The initial discussion on an unrelated branch can be found on stackoverflow.com. Thanks to hillu, tcovo and phord for their input!

Some days ago I discovered that our gitosis install did not work with redmine anymore. I could push and pull changes but could not add a new ssh key. I thought it might be caused by the redmine upgrade I did, but it was some months ago and I haven’t had any problems. The redmine logs didn’t tell me anything either.
Yesterday, I started a new project. No problems with creating it in redmine and also no problems creating a git repository.
When I tried to push, gitosis gave an error. “Permission denied..” on some file.
I connected to the the gitosis server and checked the repository folder. There was a folder backup I made and it was not owend by the gitosis user. That was causing the error. After fixing ownership of that folder, everything works again as it should.

Due to their default behavior to handle differences on a line-by-line level most of the version control systems seem to be impractical when writing texts others than source code. Also git highlights changes to text files line-wise.

After some research I found some nice options to improve things.

Coloring words using git diff

git diff --color-words

Coloring words using gitk

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

The gitk parameter option seems to be new and/or undocumented since I could neither find it on the man page of gitk nor I did get it with the auto-completion. Please find further interesting thoughts in the discussion of András Salamon on StackExchange and Eduardo’s post. Also Iain Murray’s cwdiff wrapper might be worth taking a closer look.

Gitk differences colored at line-level

Gitk differences colored at word-level

Every project you run on git wants you to configure the gitignore settings for you IDE as well as specific exclusions for the programming language you use. To simplify the process of editing the .gitignore files you can now use a handy python script. Instead of manually editing the individual you simply download a collection of well known settings and pipe them into your .gitignore file.
Please feel free to use the script that adds global and local gitignore settings for you project published by Peter.
The script allows to choose between global and local settings. Use gitignore-rules-adder.py --help to find out how it works.