Setting up Sublime Text 2 (or the new Beta Release of version 3) as the default editor used by Git is not overly challenging, but not necessarily obvious either. Really, we're still simply setting up the .gitconfig file with a path to sublime text. However, given that there is not, presently, a standard installation directory for Sublime Text, we first need to know where to point our .gitconfig file. Also, there are some non-obvious flags which need to be set as part of the configuration, or Sublime Text will not work properly as the Git editor.

If you used one of the methods above, you should now have a bash script or alias named subl in your /usr/bin/ directory which allows you to refer to Sublime Text as subl from the terminal. We will point the .gitconfig file to this.

Tell Git Where Sublime Text Lives

To set the default editor in our .gitconfig file from the terminal, we can use the following command:

$ git config --global core.editor "subl -n -w"

Notice the –n and –w flags at the end? These arguments are passed to Sublime Text, and essentially tell it to run without loading any previously open windows (the –n flag), and to wait until the user exits to pass execution back to the calling process (the –w flag, for "wait"). In this case, the calling process is Git.

Trouble Shooting

If the above doesn't work for you, then you may not have the alias or Bash script in your /usr/bin/ directory, or you may have installed Sublime Text to a different directory altogether. In this case, the command is the same, but you need to change it to include either the script name you chase, or the the full-path to Sublime Text itself:

$ git config --global code.editor "<FullPathorScript> -n -w"

Of course, you can always open the .gitconfig file in Sublime Text itself (or any other editor on your system), and edit the file directly, but if you are learning Linux, where's the fun in THAT?

If you have other issues, feel free to mention them in the comments or email me at the address in the "Author" section of this blog.

That's it. The biggest issue most people run into with this is not knowing about the –n and –w flags, which must be included in the quotes. Without these flags, Sublime Text will open in response to a prompt from Git, but will immediately return execution to Git. Therefore, your merge edits, interactive rebase, or other such activity will fail, because Git will never see your changes.

This article is targeted at those newer to Git, who may be trying to find their way through some of the more advanced features for the first time. I've created a more condensed Quick Reference to Git's Interactive Patch Staging for those who don't need that narrative or pictures, and just want to refresh themselves on the syntax and/or options associated with this feature of git.

If you are just getting started with Git, you might find Getting Started With Git and a Basic Git Command Line Reference helpful in conjunction wit this article. Both were aimed at Windows users stepping into Git and the Bash CLI for the first time, but the concepts and commands discussed are mostly universal.

If we were all perfect we would always be on top of things, and (for example) do a bug fix in one commit, and add new code in a different commit. But as we all know, in real life it doesn't actually work out that way sometimes (most of the time, if you are me!). On occasion, we perform a number of changes in the same code file, and then, after laboring to get it right for hours, we realize we have introduced unrelated changes, to different parts of the file, which should really be in separate commits.

Consider the following contrived, but illustrative situation (the examples here are in C#, but this exercise could apply to any platform). We open our latest project on branch master and review a file, ComplicatedExistingClass, which looks like this to start with:

Original Code File for ComplicatedExistingClass:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

namespace GitAddPartialFile

{

publicclass ComplicatedExistingClass

{

publicint ComplexCalculation(int numberOne, int numberTwo)

{

int sum = 0;

// Some complex code which also contains a bug . . .

sum = numberOne + numberTwo + 1;

return sum;

}

}

}

We get to work, adding a new method. We start by checking out a feature branch (because we always do that, right? Create a feature branch to work on?):

Check Out a New Feature Branch:

$ git checkout -b newfeature

We then add our new method, which requires the addition of a couple new using statements at the top of the code file (yes, I KNOW System.Data and System.Data.OleDb are not actually used here, just mixing it up a bit – work with me), and of course, our new method:

Our Code File with New Method:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using System.Data;

using System.Data.OleDb;

namespace GitAddPartialFile

{

publicclass ComplicatedExistingClass

{

publicint ComplexCalculation(int numberOne, int numberTwo)

{

int sum = 0;

// Many lines of complex code which also contains a bug . . .

sum = numberOne + numberTwo + 1;

return sum;

}

public IEnumerable<int> DoSomethingWithNumbers(int[] numbers)

{

var output = new List<int>();

foreach (int i in numbers)

{

int result = this.ComplexCalculation(i, numbers.Count());

output.Add(result);

}

return output;

}

}

}

While testing out our complicated new method, which also calls the original ComplexCalculation method, we notice there is a bug in the original method. The bug fix is quite complex, requiring us to modify several lines of code after we discern just what it is that is wrong:

Only now do we come up for air long enough to realize we should have done the bug fix separately from adding our new method. For one, we might not be done with our feature yet, but the bug fix is critical and should be able to be merged back into master immediately. Also, it simply makes sense that a bug fix in the existing code base should be a singular commit, separate from adding new code. What to do?

What we would like to do is create a commit for the bug fix first, separate from our newly added feature code. Here is how.

Git to the rescue. We can use the Git command git add –p to do this interactively, and stage our code in patches. With git add –p, we selectively add chunks of a file (or files) from our working tree to the staging area, enabling us to select discreet chunks of changed code and build separate commits with pieces of a file or files. The command syntax is as follows:

In the above, the file name is optional, but most likely you will want to specify the file, as otherwise the next step will walk you through all files within the working tree with changes since the last commit.

Once we type this command and hit enter, git jumps into an interactive mode, allowing us to decide which file chucks we wish to add to the next commit. In the case of our example project, we would type the command like this:

Staging Patches from our Existing File for Commit:

$ git add -p ComplicatedExistingClass.cs

Our terminal window looks like this before we hit enter:

Once we hit the enter key, we see this rather busy window:

See the stuff called out in the red box? this represents the first chunk of changed code git has identified in the file. The changes are shown in green, and surrounding (unmodified) code is shown in white for context. Also notice the text in blue at the bottom of the window, with a prompt waiting for us to tell git what to do. Following are the options available to us with respect to the code chunk in the box. Typing one of the options and hitting enter will do one of the following, depending upon the option selected:

In our example case here, the code chunk above is related to our new method (work with me here, it's contrived, remember?), so we we don't want to add this chunk to the next commit. Hit n, then Enter:

Do Not Stage Current Code Chunk and Move to the Next Code Chunk:

Whoa. Ok, NOW we see the bug fix code we were looking for, but we also see our newly added method. We want to isolate the bug fix code. In this case, we need to select the s option from the menu, splitting the above chunk into smaller pieces. This results in a code chunk including our bug fix, and only our bug fix:

Split Current Code Chunk and Isolate Bug Fix:

Now we have what we want to include in our next commit. Obviously, we choose the y option so that this chunk is staged for commit. Git then moves to the next code chunk:

Choose Bug Fix for Next Commit:

What we now see in the terminal window is the rest of the code for our new feature. We don't want this in our bug fix commit. Also, because our entire bug fix has just been staged for commit by selecting the y option, we can tell git not to stage the current code chunk, or any remaining code chunks. We do this by selecting the d option:

Exit and Return to Terminal Command Prompt

Now we are ready to commit our bug fix. If we run git status, we see something interesting:

Git Status After Staging Partial Code Patch for Bug Fix:

In the image above, the item under "changes to be committed" in green is our ComplicatedExistingClass.cs file. But also, we see a similar item under "Changes not staged for commit." This is because we have staged some of our changes within that file for commit, and left some un-staged.

Git Log After Committing Bug Fix and Feature Code Separately:

Additionally, we could, if we so desired, merge the bug fix back into master while keeping our feature-related changes on the feature branch. We do this by switching to master, then merging the bug fix commit using its SHA-1 identifier (the first 6-8 characters will do here):

Checkout Master Branch:

$ git checkout master

Merge Bug Fix Commit (#94327f06 . . .)

We have taken a very basic look at using Git Interactive Patch Staging to make order out of chaos, so to speak. This feature is handy because in real life, our actual workflow does not always parallel the idealized flow we want to record as our project's history. Git is a powerful tool, but requires use and practice to master and become comfortable with. Check out the additional resources below for more of my own stuff, and others.

NOTE: This is a reference, mainly for myself and others, condensed from a much more verbose article which does a lot of hand-holding for Git newcomers, and attempts to explain what is going on in a little more detail.

Once the git add –p command is executed, git enters interactive mode, and interactively moves through chunks of code in the file or files, prompting you to indicate what to do as far as staging each chunk. Following is a table of the options available with this command:

Interactive Patch Staging Options:

y

Stage the current code chuck for the next commit

n

Do not stage the current code chunk for the next commit

a

Stage the current chunk, and all remaining chunks in the current file

d

Do not stage current chuck, or any remaining chunks in the current file

On occasion, we perform a number of changes in the same code file, and then, after laboring to get it right for hours, we realize we have introduced unrelated changes, to different parts of the file, which should really be in separate commits.

Consider the following contrived, but illustrative situation (the examples here are in C#, but this exercise could apply to any platform). We open our latest project on branch master and review a file, ComplicatedExistingClass, which looks like this to start with:

Original Code File for ComplicatedExistingClass:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

namespace GitAddPartialFile

{

publicclass ComplicatedExistingClass

{

publicint ComplexCalculation(int numberOne, int numberTwo)

{

int sum = 0;

// Some complex code which also contains a bug . . .

sum = numberOne + numberTwo + 1;

return sum;

}

}

}

We then add our new method, which requires the addition of a couple new using statements at the top of the code file (yes, I KNOW System.Data and System.Data.OleDb are not actually used here, just mixing it up a bit – work with me), and of course, our new method:

Our Code File with New Method:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using System.Data;

using System.Data.OleDb;

namespace GitAddPartialFile

{

publicclass ComplicatedExistingClass

{

publicint ComplexCalculation(int numberOne, int numberTwo)

{

int sum = 0;

// Many lines of complex code which also contains a bug . . .

sum = numberOne + numberTwo + 1;

return sum;

}

public IEnumerable<int> DoSomethingWithNumbers(int[] numbers)

{

var output = new List<int>();

foreach (int i in numbers)

{

int result = this.ComplexCalculation(i, numbers.Count());

output.Add(result);

}

return output;

}

}

}

While testing out our complicated new method, which also calls the original ComplexCalculation method, we notice there is a bug in the original method. The bug fix is quite complex and takes hours, requiring us to modify several lines of code after we discern just what it is that is wrong:

Modified Code File, including Arduous Bug Fix:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using System.Data;

using System.Data.OleDb;

namespace GitAddPartialFile

{

publicclass ComplicatedExistingClass

{

publicint ComplexCalculation(int numberOne, int numberTwo)

{

int sum = 0;

// Many lines of complex code which no longer contain any bugs

// but took hours to figure out . . .

sum = numberOne + numberTwo;

return sum;

}

public IEnumerable<int> DoSomethingWithNumbers(int[] numbers)

{

var output = new List<int>();

foreach (int i in numbers)

{

int result = this.ComplexCalculation(i, numbers.Count());

output.Add(result);

}

return output;

}

}

}

Only now do we come up for air long enough to realize we should have done the bug fix separately from adding our new method. For one, we might not be done with our feature yet, but the bug fix is critical and should be able to be merged back into master immediately. Also, it simply makes sense that a bug fix in the existing code base should be a singular commit, separate from adding new code. What to do?

What we would like to do is create a commit for the bug fix first, separate from our newly added feature code. Here is how.

We can now use the git add –p to do this interactively, and stage our code in patches. With git add –p, we will selectively add chunks of a file (or files) from our working tree to the staging area, enabling us to select discreet chunks of changed code and build separate commits with pieces of a file or files.

Once we type this command and hit enter, git jumps into an interactive mode, allowing us to decide which file chucks we wish to add to the next commit. In the case of our example project, we would type the command like this:

Staging Patches from our Existing File for Commit:

See the stuff called out in the red box? this represents the first chunk of changed code git has identified in the file. The changes are shown in green, and surrounding (unmodified) code is shown in white for context. Also notice the text in blue at the bottom of the window, with a prompt waiting for us to tell git what to do. The prompt is waiting for us to enter one of the options from our table above.

In our example case here, the code chunk above is related to our new method (work with me here, it's contrived, remember?), so we we don't want to add this chunk to the next commit. Hit n, then Enter:

Do Not Stage Current Code Chunk and Move to the Next Code Chunk:

Whoa. Ok, NOW we see the bug fix code we were looking for, but we also see our newly added method. We want to isolate the bug fix code. In this case, we need to select the s option from the menu, splitting the above chunk into smaller pieces. This results in a code chunk including our bug fix, and only our bug fix:

Split Current Code Chunk and Isolate Bug Fix:

Now we have what we want to include in our next commit. Obviously, we choose the y option so that this chunk is staged for commit. Git then moves to the next code chunk:

Choose Bug Fix for Next Commit:

What we now see in the terminal window is the rest of the code for our new feature. We don't want this in our bug fix commit. Also, because our entire bug fix has just been staged for commit by selecting the y option, we can tell git not to stage the current code chunk, or any remaining code chunks. We do this by selecting the d option:

Exit and Return to Terminal Command Prompt

Now we are ready to commit our bug fix. After we do that, we can then stage our newly added feature code in the normal fashion and commit.

About the author

My name is John Atten, and my "handle" on many of my online accounts is xivSolutions. I am Fascinated by all things technology and software development. I work mostly with C#, JavaScript/Node, and databases of many flavors. Actively learning always. I dig web development. I am always looking for new information, and value your feedback (especially where I got something wrong!). You can email me at: