Git Tip of the Day – introduction text when emailing patches

You have created a great patch and want to send it to project maintainers, but you don’t want to create all the emails by hand (that means opening your email client and copy-n-pasting the patch into the message or – god forbid – adding those patches as attachments). At the same time you would like to provide some introduction text for your patches. How do you do that?

First option: use send-email --compose

git send-email is able to send the patches for you. If you use the --compose option, you will be able to write up an introduction that will be sent as the first email of the whole email series.

Second option: use format-patch --cover-letter

git format-patch creates a series of patches nicely formatted to be used as email bodies. The output is one file per commit. The magical option --cover-letter will create one more file, probably called 0000-cover-letter.patch, that you can use for introduction of your changes. This file will also contain a short summary of your patch series, including author names, commit messages and changed files. Neat.

Third option: misuse git patch syntax

If you have just a single commit change and you don’t like sending multiple emails, but you still want to provide further information (besides commit message), you can misuse the git patch syntax and smuggle some further information into it without affecting the very patch.

Let’s see a sample patch generated with git format-patch:

From 7ea3c50fa83950549de11c6834c465bc8f28b52b Mon Sep 17 00:00:00 2001
From: James Laska
Date: Mon, 1 Aug 2011 09:53:16 -0400
Subject: [PATCH] compose_tree - Save the setup.sh script for later debugging

---
 tests/compose_tree/compose_tree.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tests/compose_tree/compose_tree.sh b/tests/compose_tree/compose_tree.sh
index 66ecefd..c2e041d 100755
--- a/tests/compose_tree/compose_tree.sh
+++ b/tests/compose_tree/compose_tree.sh
@@ -204,6 +204,8 @@ let RETVAL+=$?

 # Report the results.  We do all the copies individually in case one of the files doesn't exist.
 mkdir -p ${RESULTSDIR}
+cp -f ${SETUP} ${RESULTSDIR}/setup.sh
+let RETVAL+=$?
 cp -f ${MOCKROOTDIR}/${KSCFG} ${RESULTSDIR}/ks.cfg
 let RETVAL+=$?
 cp -f ${MOCKROOTDIR}/../result/root.log ${RESULTSDIR}/
--
1.7.6

Now, if you look up the space between --- and tests/compose_tree/compose_tree.sh, that’s our secret spot. You can add any text in there, it will be visible to the developers, but it will not affect the patch. It then might look like this:

From 7ea3c50fa83950549de11c6834c465bc8f28b52b Mon Sep 17 00:00:00 2001
From: James Laska
Date: Mon, 1 Aug 2011 09:53:16 -0400
Subject: [PATCH] compose_tree - Save the setup.sh script for later debugging

---
This patch is really really important, because otherwise the world will end in
2012. Please accept it.
 tests/compose_tree/compose_tree.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tests/compose_tree/compose_tree.sh b/tests/compose_tree/compose_tree.sh
index 66ecefd..c2e041d 100755
... (the rest of the patch)

Don’t we love it, having so many options? I’m sure there are more of them, but I like these three.

Enjoy!

Git Tip of the Day – syntax highlighting for commit messages

If your favorite editor is vim, you surely already noticed that even with default configuration you’ll get a nice syntax highlighting for commit messages. It notifies you if your commit message is too long, it auto-wraps long lines in the description. Pretty.

 

 

But sometimes all of this does not work. You still get only black and white display, no colors, no highlighting, nothing. My colleague spent two hours of googling for vim documentation, adjusting configuration, copying my configuration, to no avail.

Well if you reached that point in your life, and I believe some of you did (according to similar problems mentioned throughout the Internets), then…

… just ensure vim is your default editor, will you? 😀

Because vi is the default editor in Fedora. If you don’t put something like

export EDITOR=vim

into your ~/.bashrc or somewhere, then you have vi by default. And that does not do any of that pretty stuff.

The solution can be simple, but sometimes it can be really hard to find. Enjoy the day.

Git Tip of the Day – detect moved files

When you rename your files in your project, git may display that as removing and adding the file. Let’s see a demo.

Let’s prepare a commit where we rename a file:

$ mv foo bar
$ git add -A
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	renamed:    foo -> bar
#
$ git commit -m 'improve naming'
[master 80d5850] improve naming
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename foo => bar (100%)

Now let’s show the default behavior of git:

$ git show
commit 80d5850fa16ecc783fa86a1d474c4324ec9f4c2d
Author: Kamil Páral
Date:   Wed Aug 3 13:49:01 2011 +0200

    improve naming

diff --git a/bar b/bar
new file mode 100644
index 0000000..4e4b354
--- /dev/null
+++ b/bar
@@ -0,0 +1,2 @@
+this is a
+sample file
diff --git a/foo b/foo
deleted file mode 100644
index 4e4b354..0000000
--- a/foo
+++ /dev/null
@@ -1,2 +0,0 @@
-this is a
-sample file

You will get the same output with git diff, git format-patch or git log -p. Basically the whole file is removed and added back again in another location. This is not great, because if the file has 1000 lines, then it will really clutter your view. There is a better approach:

$ git show -M
commit 80d5850fa16ecc783fa86a1d474c4324ec9f4c2d
Author: Kamil Páral
Date:   Wed Aug 3 13:49:01 2011 +0200

    improve naming

diff --git a/foo b/bar
similarity index 100%
rename from foo
rename to bar

We shortened the output to 4 simple lines. You see that similarity index is 100%, that means the files are the same, just at different locations (i.e. with different names). The similarity index can be lower, that means git can detect even files that changed a little during the move. The threshold can be set as an argument to the -M option.

If you use this option for patch creation, you may get a much shorter patches that are much more readable. The disadvantage? They are no longer “standard” patches that can be applied with patch command, you must use git to do that.