Git: Setting Sublime Text as the Default Editor for Git (Linux Mint/Ubuntu)

Posted on September 10 2013 08:58 PM by jatten in CodeProject, Git, Linux   ||   Comments (0)

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.

Installing Sublime Text 2, or installing the beta release of Sublime Text 3 is not too challenging either, but again, to this point neither Linux Mint nor Ubuntu offer Sublime as part of the Synaptic Package Manager for either distro. For additional help on this, refer to my previous posts:

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 "<Full Path or Script> -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? Smile

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.

Other Articles of Interest to Git or Linux Newcomers

 

Posted on September 10 2013 08:58 PM by jatten     

Comments (0)

Git: Interactively Stage Portions of a Single Changed File for Commit Using git add -p

Posted on September 8 2013 01:38 PM by jatten in CodeProject, Git   ||   Comments (0)

Terminal 9 - the Hong Kong International Container Port-500The thing which makes Git powerful as a version control system is its flexibility, and the many ways exposed by the Git API to get things done.

Of course, this is also what can make Git challenging to learn and use. There are so many options available that it can be difficult to know how to approach a specific problem.

On top of that, the Command Line Interface (CLI) for Git, and the underlying API employ a syntax which is . . . inconsistent at times, and definitely not intuitive for the uninitiated.

 

Image by Kai Yan, Joseph Wong, Some Rights Reserved

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.

Skip the damn narrative and pictures, take me to the quick version

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.

Don't Put Several Significant but Unrelated Changes in the Same Commit

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.

Our Contrived Example

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
{
    public class ComplicatedExistingClass
    {
        public int 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
{
    public class ComplicatedExistingClass
    {
        public int 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:

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
{
    public class ComplicatedExistingClass
    {
        public int 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;
        }
    }
}

 

We're Ready to Commit, but . . .

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.

Use Interactive Staging with Partial Files for Separate, Individual Patch Commits

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:

Git Add –P Syntax:
$ git add -p [optionalFileName]

 

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:

git-add-p-before-enter

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

git-add-p-after-enter-one

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:

Options for Interactive Patch Staging:

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
g Select the next code chuck to review
/ Search for a code chuck matching the given regex
j Leave undecided, see next undecided chunk
k Leave undecided, see next code chunk
K Leave undecided, see previous undecided code chunk
s Split the current code chunk into smaller chunks
e Manually edit the current code chunk
? Print help

 

Staging Just the Bug Fix For Commit

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:

git-bash-interactive-next-chuck-bug-fix-needs-split

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:

git-bash-interactive-split-to-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:

git-bash-interactive-choose-bug-fix-for-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

git-bash-interactive-exit-and-return-to-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:

Git Bash-git-status-after-stage-bugfix

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.

 

Committing the Staged Patches from the File:

From here, we can commit the bug fix:

$ git commit -m "Fixed bug in Complicated Calculation Method"

 

Commit the Bug Fix:

git-bash-commit-bug-fix

If we run git status again, we see that there are no changes staged for commit, and a single item modified but un-staged – the rest of our changes representing the addition of our new method:

Git Status After Committing Bug Fix:

Git Bash-git-status-after-commit-bugfix

 

Stage and Commit the New Feature Code

Now that we have our bug fix committed, we can (in this case) go ahead and stage the rest of the changes for as usual, and then commit, since they represent our complete work adding the new method:

Stage New Feature Changes:
$ git add .
Then Commit:
$ git commit -m "Added DoSomethingWithNumbers method as part of newfeature"

 

Our terminal window:

Stage and Commit the New Feature Code:

git-bash-commit-featture

 

Review Commit History with git log

Now, if we use git log to review our commit history, we see our nicely broken out commits as if the bug fix, and the new feature code had happened sequentially instead of in parallel:

Git Log After Committing Bug Fix and Feature Code Separately:

git-log-after-commit-feature

 

Merge the Bug Fix into Master

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 . . .)
$ git merge 94327f06

 

Our terminal window:

git-merge-bugfix-into-master

 

Wrapping Up

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.

Additional Resources

 

Posted on September 8 2013 01:38 PM by jatten     

Comments (0)

Git Quick Reference: Interactive Patch Staging with git add -p

Posted on September 8 2013 01:36 PM by jatten in Git, CodeProject   ||   Comments (0)

Port of Long Beach-500NOTE: 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. 

Also, if you are newer to Git you might want to review my introductory posts on Getting Started with Git and a Handy Git Command Line Reference. While these tutorials were originally targeted at Windows developers, the information is pretty universal. Also, you might benefit from the more through treatment of this topic in the full-fledged walk-thru.

 

Image by msun523 Some Rights Reserved

I'm new and/or I enjoy reading. Take me to a full-fledged walk-through!

The git add –p Command and Syntax

The git add –p command allows us to interactively stage chunks of code within a file or files for commit, while leaving the rest of the file of files un-staged. The command syntax is:

The git add –p Command Syntax:
$ git add -p [optionalFileName]

 

In the above, the file name is optional, but without a specific file name, git will interactively move through all files with un-staged changes. Best to include only the file or files of interest.

git add –p Command Options

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
g Select the next code chuck to review
/ Search for a code chuck matching the given regex
j Leave undecided, see next undecided chunk
k Leave undecided, see next code chunk
K Leave undecided, see previous undecided code chunk
s Split the current code chunk into smaller chunks
e Manually edit the current code chunk
? Print help

 

Example Usage Scenario

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.

Contrived Example

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
{
    public class ComplicatedExistingClass
    {
        public int 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
{
    public class ComplicatedExistingClass
    {
        public int 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
{
    public class ComplicatedExistingClass
    {
        public int 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.

Use git add –p to Stage Our Bug Fix Separately From the New Feature Code

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:
$ git add -p ComplicatedExistingClass.cs

 

What it Looks Like in the Terminal

Our terminal window looks like this before we hit enter:

git-add-p-before-enter_thumb[3]

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

git-add-p-after-enter-one_thumb[10]

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:

git-bash-interactive-next-chuck-bug-fix-needs-split_thumb[3]

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:

git-bash-interactive-split-to-bug-fix_thumb[3]

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:

git-bash-interactive-choose-bug-fix-for-commit_thumb[2]

 

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

git-bash-interactive-exit-and-return-to-prompt_thumb[2]

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.

More Detail?

In this article I walked through this as briefly as I could while including sufficient examples and illustrative screenshots to show what is going on. There is more detail in the full tutorial Git: Interactively Stage Portions of a Single Changed File for Commit Using git add –p.

If you found this useful, consider some of my other posts related to Git, and as always, the most excellent book (free online) by Scott Chacon:

Additional Resources

 

Posted on September 8 2013 01:36 PM by jatten     

Comments (0)

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:

jatten at typecastexception dot com

Web Hosting by