Updating GIMP for artists and photographers

This is Part 2 of a three-part series of articles. Part 1 shows you how to build high bit depth GIMP from git in a prefix. Part 2 (this page) shows you how to keep up with the latest changes in GIMP from git. Part 3 shows you how to build a version of GIMP that's patched to allow editing in non-sRGB color spaces, which is useful during the span of time between now and when default high bit depth GIMP finally has support for editing in user-chosen RGB working spaces.

Written June 2015. Updated May 2016.

Note: This page is a work in progress. I haven't finished the last two sections, and I'm not sure when I'll find the time. In the meantime, what's here might prove useful if you are trying to build and update GIMP from git for the very first time.

Introduction

This article walks you step by step through the process of updating babl, GEGL, and GIMP from git. The article assumes that you've already successfully built babl, GEGL, and GIMP from git in a prefix, preferably following Building GIMP for artists and photographers. And now you'd like to update to pull in the latest code changes.

The commands on this page assume that your babl/GEGL/GIMP prefix folder is located at $HOME/code/gimpdefault, with this folder structure. If this assumption is correct, you can copy-paste the commands on this page. If not, you'll need to modify the commands to reflect your actual folder structure.

A major goal of this article is to take some of the mystery out of working with git at the command line. So the best way to read this article is to have a terminal open and follow along step by step.

Updating babl, GEGL, and GIMP from git

As a reminder, once you've installed glib (and gdk-pixbuf and whatever other libraries were required by your particular Linux installation) in your babl/GEGL/GIMP prefix, there's no reason to update these packages again until GIMP complains about a version bump when you try to rebuild GIMP.

Establish the prefix

Development of babl, GEGL, and GIMP is an on-going process. Keeping up with the latest developments is usually pretty straightforward. The first step is to open a terminal and establish the gimpdefault prefix. Technically you don't need to establish the prefix until you are ready to start rebuilding the updated babl, GEGL, and GIMP. But it doesn't hurt to establish the prefix before you update babl, GEGL, and GIMP (and doing so might keep you from accidentally installing the updated babl, GEGL, and GIMP somewhere other than in the prefix):

# Open a terminal and establish the prefix
# Don't forget to modify the lines with "lib" and "gio" to match your Linux distribution!
PREFIX=$HOME/code/gimpdefault/install
export PATH=$PREFIX/bin:$PATH
export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS
export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal"
export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
export GIO_EXTRA_MODULES=/usr/lib/gio/modules
export SRC_DIR=$HOME/code/gimpdefault/build

Check the status of babl, GEGL, and GIMP

The next step is to check the status of the babl, GEGL, and GIMP code from git:

# Check git status
cd $SRC_DIR/babl
git status

cd $SRC_DIR/gegl
git status

cd $SRC_DIR/gimp
git status

Unless you start making your own modifications to the babl, GEGL, or GIMP code, usually the only thing that will be reported when you check "git status" is the presence of files (that git will call untracked files) that aren't part of the official code that was downloaded from git.

Following are some examples of what "git status" might report. Text in magenta is what I typed in at the terminal and text in blue is what was subsequently printed to the terminal screen:

elle@gentoo ~/code/gimpdefault/build/gimp $ cd $SRC_DIR/babl
elle@gentoo ~/code/gimpdefault/build/babl $ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add ..." to include in what will be committed)

        disable-babl-flips.patch
        tests/n_components_cast

nothing added to commit but untracked files present (use "git add" to track)

OK, so the obvious question is "what does all that terminal output actually mean? Breaking it down into bite-sized chunks:

On branch master
This requires a little background to explain. Git is set up so that you can duplicate the existing code into a new "branch" and then make changes in the branch without affecting code that's in other branches. The main branch is called "master". Unless and until you have a really good reason to mess with branches, don't. Just stay with git master.
Your branch is up-to-date with 'origin/master'.
This is actually a bit misleading. "Your branch" is actually "master", or rather your local copy of master. And your local master branch isn't necessarily up-to-date with the newest code that's been added to babl's official git repository, which is hosted on the GNOME git server. You won't know if your local branch is up-to-date with the "real" master branch of babl until you issue the command "git pull", which we haven't gotten to yet. So what this statement really means is that since the last time you updated your code, you haven't subsequently reverted to an earlier point in the code. Let's postpone the topic of "reverting" until later.
Untracked files:
"Untracked files" means there are files in the babl code folders that git doesn't know about. This is nothing to worry about, though you can delete the untracked files if you want to. Many times they'll just be recreated the next time you compile babl, GEGL, or GIMP. So it's also safe to just ignore untracked files.
(use "git add ..." to include in what will be committed)
This means that you have the option to tell git to keep track of the untracked files. Most of us will seldom or never have any reason to tell git to track a previously untracked file.

The only reason you would want to tell git to track a previously untracked file is if you were actually modifying rather than just updating the babl code; your modifications required writing a new code file rather than just modifying an existing code file; and you were ready to add the new code file to the files that git already tracks.
disable-babl-flips.patch tests/n_components_cast
Well, this is pretty obvious. It's just the list of untracked files. The first item is a patch file (patch files are used to modify code, but I haven't yet applied this patch, and this article doesn't cover writing and applying patches). The second item is a folder that will probably be recreated even if you delete it.

There are in fact a whole lot of untracked files in babl, GEGL, and GIMP that you will never see listed when you type "git status". These files are created when you build babl, GEGL, and GIMP, and the developers put most of them on a list of files to ignore, so you'll never see them listed.
nothing added to commit
This means you haven't changed any of the babl code files that git is currently tracking. If you were modifying code to make changes in how babl operates, you'd see the modified files listed when you checked the git status, until such time as you decided to tell git to commit the modified code. But for now you don't need to worry about making or committing changes in the code.
but untracked files present (use "git add" to track)
This is just a reminder that there really are some untracked files, plus a reminder of what command to use if you want git to track these files (again, almost certainly you'll never want to do this).

Below are additional examples of what "git status" might report:

elle@gentoo ~/code/gimpdefault/build/babl $ cd $SRC_DIR/gegl
elle@gentoo ~/code/gimpdefault/build/gegl $ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add ..." to include in what will be committed)

        operations/workshop/external/ff-save.c.h
        operations/workshop/external/gluas.c.h
        operations/workshop/external/lens-correct.c.h
        operations/workshop/external/line-profile.c.h
        operations/workshop/external/v4l2.c.h
        perf/test-samplers
        tests/simple/test-gegl-color

nothing added to commit but untracked files present (use "git add" to track)

The above terminal output is basically a repeat of what you saw from checking the status of the babl code. The only difference is the list of files are untracked. And again, you can delete these untracked files, or just ignore them.

If you don't delete the untracked files every once in a while, the list of untracked files grows over time as the developers move code around (which they try to not do, but sometimes it's necessary). So here's the command for deleting the untracked files listed above. Please read the warning in the box below the commands before you try deleting files from the command line!

elle@gentoo ~/code/gimpdefault/build/gegl $ rm operations/workshop/external/ff-save.c.h
rm operations/workshop/external/gluas.c.h
rm operations/workshop/external/lens-correct.c.h
rm operations/workshop/external/line-profile.c.h
rm operations/workshop/external/v4l2.c.h
rm -r perf/test-samplers
rm -r tests/simple/test-gegl-color

Before moving on, please be aware that deleting files at the command line is something you should never do without thinking twice, three times, and yet again.

"rm" for a specific file isn't so bad (eg "rm operations/workshop/external/gluas.c.h"), because you are only deleting the one file.

But "rm -r" (eg "rm -r perf/test-samplers") deletes recursively, folder by folder, file by file, until it runs out of folders and files to delete. So if you execute "rm -r" in the wrong folder, you might end up deleting a whole lot of files and folders that you didn't intend to delete, and there's no Trash from which you can retrieve the deleted files.

Once you delete a file using "rm" or worse, "rm -r", your options are hiring a specialist in recovering lost files (for example Dave Coffin, author of dcraw), or else locating some file recovery software and trying to recover those files yourself. In either case, it's better if you immediately stop using your computer until you come up with a plan for how to recover your deleted files.

So unless you are sure you know exactly what you are doing, don't use the "rm -r" command. Don't even use "rm name-of-file". Use your file manager instead so you can pull the files out of the Trash if you made a mistake.

OK, with the obligatory and very serious warning about "rm -r" out of the way, let's move on to checking the status of GIMP's git:

elle@gentoo ~/code/gimpdefault/build/gegl $ cd $SRC_DIR/gimp
elle@gentoo ~/code/gimpdefault/build/gimp $ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

This time there's a bit of new output. Because there aren't any tracked files that have been modified, git tells you that there is "nothing to commit". And because there aren't any untracked files, git tells you the "working directory" is "clean". (In reality there are most likely a whole lot of untracked files. But these files are generated during the GIMP build process, and thankfully they are all on GIMP's list of files for git to ignore. So you'll never see these files listed when you type "git status".)

Unless you start deliberately modifying tracked files, the sample output shown above pretty much covers everything you ever see when you "cd" to the babl, GEGL, or GIMP code folders and type "git status".

Update babl, GEGL, and GIMP to pull in the latest code

So you've checked "git status" and there's nothing to worry about. If you really had modified any of the tracked code files, you'd need to "stash" the modifications before updating babl, GEGL, and GIMP, or else "commit" the changes to git. But stashing or committing modified files isn't relevant to what we are doing right now. All we want to do is update code that we've never modified.

So the next step is to update the babl, GEGL, and GIMP code. We are going to use the command "git pull --rebase". This command will merge any changes you've made in your local copy of git master with new code that you pull from the copy of git master that the devs are working on, that's located on the GNOME git servers. Again, you haven't actually made any changes.

#git pull --rebase
cd $SRC_DIR/babl
git pull --rebase

cd $SRC_DIR/gegl
git pull --rebase

cd $SRC_DIR/gimp
git pull --rebase

Following are examples of what you'll see when you run the "git pull --rebase" command. Again, text in magenta is what I typed in at the terminal and text in blue is what was subsequently printed to the terminal screen:

#babl
elle@gentoo ~/code/gimpdefault/build/babl $ cd $SRC_DIR/babl
elle@gentoo ~/code/gimpdefault/build/babl $ git pull --rebase
Current branch master is up to date.

OK, we updated our local copy of the babl code to pull in any changes that have been made in the babl code that's on the GNOME git server, and it turns out that nothing has changed since the last time we updated. This is normal. Babl code doesn't change nearly as fast as GEGL and GIMP code.

#GEGL
elle@gentoo ~/code/gimpdefault/build/babl $ cd $SRC_DIR/gegl
elle@gentoo ~/code/gimpdefault/build/gegl $ git pull --rebase
remote: Counting objects: 58, done.
remote: Compressing objects: 100% (47/47), done.
remote: Total 47 (delta 33), reused 0 (delta 0)
Unpacking objects: 100% (47/47), done.
From git://git.gnome.org/gegl
   1cbe63f..52107ac  master     -> origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 52107acee7d2ee91c9cdc2d4411d8ae57d6925ba.

We updated our local copy of the GEGL code by pulling in changes that have been made in the GEGL code on the GNOME git server. And it turns out that changes have been made since the last time we updated. So let's go through the terminal output and see what it all means:

remote: Counting objects: 58, done. remote: Compressing objects: 100% (47/47), done. remote: Total 47 (delta 33), reused 0 (delta 0) Unpacking objects: 100% (47/47), done. From git://git.gnome.org/gegl 1cbe63f..52107ac master -> origin/master
This just tells you that there was in fact new code in the master branch of the GEGL code that's on the GNOME git server, and the new code has been downloaded to your local master branch.

Actually the (admittedly somewhat cryptic) terminal output tells you a little more than what I just said. See the funny number "1cbe63f..52107ac"? That is the ID number of the last commit that was downloaded the last time the GEGL code was updated from git master, except only the first and last part of the ID number are shown, with ellipses in the middle. See the second and fourth items below for explanations of "ID number" and "commit":
First, rewinding head
This is a bit complicated, but very important. Let's say the developers are working on a particular bit of code. They might make several changes in a file before they are satisfied that the new code works. Git will notice the changes, and if you check the git status, git will say the file has been modified. But git won't actually track the modified code until the developers commit the modified code.

Making a commit basically tells git that the new modifications should be made an official part of the history of changes that git is tracking. "[R]ewinding head" means that git is taking the code it tracks back in time, commit by commit, to the point where any changes you might have committed to your local master branch can be merged with commits made on the GEGL master branch that's on the GNOME git server.
to replay your work on top of it...
Well, at this point, this is a little misleading, because you haven't actually made any changes ("your work") that need to replayed. But if you really had made any changes, this is where git would merge (try to, sometimes merges fail) your changes with the code that's on the GEGL master branch that's on the GNOME git server.
Fast-forwarded master to 52107acee7d2ee91c9cdc2d4411d8ae57d6925ba.
Every commit made to code files that git tracks is given a unique identifying number. The last new commit that you just downloaded from the GEGL master branch that's on the GNOME git server has the commit id "52107acee7d2ee91c9cdc2d4411d8ae57d6925ba".

Now let's update the GIMP code:

#GIMP
elle@gentoo ~/code/gimpdefault/build/gegl $ cd $SRC_DIR/gimp
elle@gentoo ~/code/gimpdefault/build/gimp $ git pull --rebase
remote: Counting objects: 2006, done.
remote: Compressing objects: 100% (285/285), done.
remote: Total 1420 (delta 1172), reused 1373 (delta 1135)
Receiving objects: 100% (1420/1420), 430.68 KiB | 257.00 KiB/s, done.
Resolving deltas: 100% (1172/1172), completed with 318 local objects.
From git://git.gnome.org/gimp
   1e8b9f4..1615252  master     -> origin/master
   5b2bdbd..6280cd0  gimp-2-8   -> origin/gimp-2-8
  + 0c925c3...061b0cc gtk3-port  -> origin/gtk3-port  (forced update)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 1615252ced77c11d9e9904e86e35cb97f1277d9f.

Looking at what git has told us:

remote: Counting objects: 2006, done. remote: Compressing objects: 100% (285/285), done. remote: Total 1420 (delta 1172), reused 1373 (delta 1135) Receiving objects: 100% (1420/1420), 430.68 KiB | 257.00 KiB/s, done. Resolving deltas: 100% (1172/1172), completed with 318 local objects.
OK, you've already seen this when you updated GEGL. This just tells you that there was in fact new code in the master branch of the GIMP code that's on the GNOME git server, and the new code has been downloaded to your local master branch.
From git://git.gnome.org/gimp 1e8b9f4..1615252 master -> origin/master 5b2bdbd..6280cd0 gimp-2-8 -> origin/gimp-2-8 + 0c925c3...061b0cc gtk3-port -> origin/gtk3-port (forced update)
This is new. Remember branches? Every git code repository has a master branch. And often there are other branches. The GIMP code that's on the GNOME git server has quite a few branches, and three of the branches have been updated since the last time you updated the GIMP code.

You could actually switch to any of the GIMP branches, right on your local copy of the GIMP code. But I haven't told you how to change branches, and you really don't want to change branches. You want to stay on the master branch.

If there ever comes a time when you need to switch branches, hopefully you will already know why, how, and when to do so. But for our purposes, just ignore all the branches except the master branch. For our purposes, we really don't care what's happening on the other branches.
First, rewinding head to replay your work on top of it... Fast-forwarded master to 1615252ced77c11d9e9904e86e35cb97f1277d9f.
Again, we've already seen this when we updated GEGL. If you had made and committed changes to your local copy of the GIMP master branch, this is where git would try to merge your changes with changes that were committed to the master branch of the GIMP code that's on the GNOME git server.

Visit the babl, GEGL, and GIMP git repositories:

OK, while explaining how to update the babl, GEGL, and GIMP code, I also gave you links to the code hosted on the GNOME git servers. Before continuing with the rest of this page, you'll probably find it very informative to take a break and go visit and maybe explore the actual git repositories, so here are the links again:

babl: babl is a dynamic, any to any, pixel format translation library.
GEGL: GEGL (Generic Graphics Library) is a graph based image processing framework.
GIMP: GNU Image Manipulation Program.

Rebuild and install babl, GEGL, and GIMP from git

Now that you've updated babl, GEGL, and GIMP, rebuilding and then installing the updated code is very simple. If you didn't already establish the prefix, go ahead and do that now. Even if you did, it never hurts to paste the commands into the terminal again:

# Open a terminal and establish the prefix
# Don't forget to modify the lines with "lib" and "gio" to match your Linux distribution!
PREFIX=$HOME/code/gimpdefault/install
export PATH=$PREFIX/bin:$PATH
export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS
export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal"
export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
export GIO_EXTRA_MODULES=/usr/lib/gio/modules
export SRC_DIR=$HOME/code/gimpdefault/build

Now that the prefix has been established, you can rebuild and install babl, GEGL, and GIMP:

# touch the gimp "m4" file
touch $HOME/code/gimpdefault/install/share/aclocal/gimp-2.0.m4

# rebuild and install babl
cd $SRC_DIR/babl
make -j3
make install

# rebuild and install GEGL
cd $SRC_DIR/gegl
make -j3
make -j3 install

# rebuild and install GIMP
cd $SRC_DIR/gimp
make -j3
make -j3 install

Copy-pasting each command individually and waiting for the command to finish before typing the next command is tedious. And copy-pasting all the individual commands at once means that if babl or GEGL fails to install before GIMP is installed, you might not catch the errors printed to screen, and then your GIMP installation would be out of step with your babl or GEGL installation.

So here are the rebuild and install commands written as just one long command:

touch $HOME/code/gimpdefault/install/share/aclocal/gimp-2.0.m4 && cd $SRC_DIR/babl && make -j3 && make install && cd $SRC_DIR/gegl && make -j3 && make -j3 install && cd $SRC_DIR/gimp && make -j3 && make -j3 install

When pasted as one long command, the make-install processes will stop as soon as something causes any of the individual "make" or "make install" steps to throw an error. This gives you a chance to notice the error and figure out how to fix the problem.

If you don't know what the "-j3" switch does, see this explanation, and of course substitute the number of cores you have on your own computer. Leaving the switch out altogether won't hurt (just type "make" instead of "make -j3"), but the software will take longer to build. And if you have more cores, using the right number means the software will build faster.

Now what's that "touch" command doing, you might be asking. That is an excellent question. One of the steps for building babl, GEGL, and GIMP was to create a file called "gimp-2.0.m4" that is located in the "$PREFIX/share/aclocal" folder. And one of the steps in setting up the prefix was:

export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal"

Here is my understanding of what these two very important steps for building babl, GEGL, and GIMP accomplish:

The "export" command ensures that the "make" command for GIMP does realize where to find the babl and GEGL libraries. This solves a problem that used to happen quite a lot, which was that if you also had babl, GEGL, and GIMP installed from your Linux repository, sometimes GIMP in the prefix would look for babl and GEGL in "/usr", even though the act of setting up a prefix is supposed to keep this "looking elsewhere" from happening.
And the "touch" command ensures that the make command for making GIMP takes into account the fact that the installed libraries for babl and GEGL might have changed.

If you have a better or more accurate way to explain these two steps, please send me an email and I'll revise the above explanation. In the meantime, I will tell you from experience that you really do want to include these steps when setting up a prefix and rebuilding GIMP (older guides for building babl, GEGL, and GIMP sometimes leave these two steps out).

Checking the git log to see what's changed

The whole point of updating the babl, GEGL, and GIMP code is to pull in the latest changes to the code. So it would be nice if you could actually see what the latest changes are. Maybe there's a change you've been waiting for, like a fix to a bug report. And maybe there's even a change that you don't actually want.

As already noted, git keeps track of every change made to the code. And you can see the whole history of every change ever made by checking the git log. The easiest command to do so is just "git log", which will spill out changes all the way back to the very first commit ever made. That's a lot of commits. But fortunately "git log" prints the changes to the terminal one screenful at a time.

Checking the GIMP git log after the update that was made in the previous section shows a whole bunch of new commits, but I'm only going to show you the last three commits, all of which were made by Michael ("Mitch") Natterer. Mitch is the head GIMP developer. Every software project has a head developer, and without Mitch, I suspect GIMP might not even exist any more.

cd $HOME/code/gimpdefault/build/gimp
git log

commit 1615252ced77c11d9e9904e86e35cb97f1277d9f
Author: Michael Natterer 
Date:   Tue Jun 9 23:56:35 2015 +0200
    plug-ins: get rid of GtkObject in jpeg-save.c
    Reduces the diff in gtk3-port, and was wrong in some cases anyway.

commit 4145fbbed78d8bf4703ac7d79b33d909ca66e219
Author: Michael Natterer 
Date:   Tue Jun 9 20:59:34 2015 +0200
    app: use gimp_image_set_color_profile() in gimp_image_convert_type()
    instead of calling gimp_image_set_icc_profile().

commit 685f883f3e52856d17e8e15dd4eed90cb9e63ab3
Author: Michael Natterer 
Date:   Tue Jun 9 18:55:07 2015 +0200
    app: add gimp_image_validate_color_profile()
    and use it from gimp_image_set_icc_profile() and from
    gimp_image_set_color_profile().

I only copy-pasted the last three log entries. If you went ahead and checked the log yourself to see the rest of the entries, you might be wondering how to get out of the log and back to the terminal. Type the letter q, lower case: "q".

If you haven't yet checked the GIMP git log, you really should. It's very educational. You'll see that right now a lot of work is being done to update various language translations. And you'll see that Mitch has been rewriting the ICC profile conversion code pretty much from top to bottom. If you check further back in time, various other parts of the code are receiving varying amounts of attention. It's a massive code base and the result of a massive team effort.

The simple command "git log" does the job. But if you type "git log --help" you'll see that there are a lot of ways to modify what "git log" will show you. Here's the command that I use most of the time, again showing only the last three entries:

cd $HOME/code/gimpdefault/build/gimp
git log --name-only --after='January 1, 2015'

commit 1615252ced77c11d9e9904e86e35cb97f1277d9f
Author: Michael Natterer 
Date:   Tue Jun 9 23:56:35 2015 +0200
    plug-ins: get rid of GtkObject in jpeg-save.c
    Reduces the diff in gtk3-port, and was wrong in some cases anyway.
plug-ins/file-jpeg/jpeg-save.c

commit 4145fbbed78d8bf4703ac7d79b33d909ca66e219
Author: Michael Natterer 
Date:   Tue Jun 9 20:59:34 2015 +0200
    app: use gimp_image_set_color_profile() in gimp_image_convert_type()
    instead of calling gimp_image_set_icc_profile().
app/core/gimpimage-convert-type.c

commit 685f883f3e52856d17e8e15dd4eed90cb9e63ab3
Author: Michael Natterer 
Date:   Tue Jun 9 18:55:07 2015 +0200
    app: add gimp_image_validate_color_profile()
    and use it from gimp_image_set_icc_profile() and from
    gimp_image_set_color_profile().
app/core/gimpimage-profile.c
app/core/gimpimage-profile.h

OK, so the output looks pretty much the same, except it shows the actual files that were changed by each commit (why "--name-only" would show the files that were modified is a mystery). And if I kept paging down, the log would stop when it reach January 1, 2015.

Here's an example of how to limit the output to only commits made by a specific author (you can use just part of the name, but you might pull up more than one author). This time let's check the babl git log:

cd $HOME/code/gimpdefault/build/babl
git log --name-only --author='Elle'

commit 2faa3e05a5f2327b8b7a72e92e4e3f6e623c3d38
Author: Elle Stone 
Date:   Sat Feb 7 12:12:46 2015 -0500
    Change constants to match built-in sRGB profiles. modified: babl/base/rgb-constants.h
babl/base/rgb-constants.h

commit 0dba0608bd2cfe69453834c1ec87b7a2be13d2dd
Author: Elle Stone 
Date:   Mon Dec 29 16:42:50 2014 -0500
    Modify CIE color space conversions to use D50-adapted sRGB
extensions/CIE.c

Hmm, it looks like Elle Stone (that's me) has made two commits to the babl code. Well, actually I don't have "commit rights", so the head babl developer made the actual commits. But I did write the patches that made the changes to the code.

It turns out that making small code changes is actually pretty easy (and surprisingly enjoyable) once you dive in and give it a try. And there are always bugs that need fixing and enhancements to be made. So if you ever find that you have an urge to write some code, contributing patches to babl, GEGL, and GIMP is a great way to get started.

Here's one last example of limiting what the git log will show you, this time asking the GIMP git log to only show commits that contain the word (or partial word) "plug", that were made before January 1, 1998 (and again only showing the first three entries; also I removed the author information in the interest of privacy because 1998 was a long time ago):

cd $HOME/code/gimpdefault/build/gimp
git log --before='January 1, 1998' --grep=plug

commit bec0b7073c2e350a601f3aa9bc603c166eecb56d
Date:   Mon Dec 29 20:57:55 1997 +0000
    updated gimp/plug-ins/ifscompose.c gimp/plug-ins/libgck/gck/gcknotebook.c
    updated
    gimp/plug-ins/ifscompose.c
    gimp/plug-ins/libgck/gck/gcknotebook.c
    to match gtk wrt gdk_pixmap_unref->gdk_pixmap_destroy

commit 33c454a73ee00a21cf2f9069d0ff430212e2a686
Date:   Fri Dec 26 07:08:20 1997 +0000
    Updated various plugins with new versions from the registry

commit c7f298c3308da767d6a42f96fcf3f982e8a6bdbe
Date:   Tue Dec 16 13:27:26 1997 +0000
    remove auto-generated files, so the correct path
    goes into the plugins

OK, here's a challenge: use the "--before=" option to locate the first entries in the babl, GEGL, and GIMP git logs. And then let's move on to the next topic, which is what to do when something goes wrong and you want to start over with "autogen.sh".