What makes gmaster a different Git GUI?

Thursday, February 15, 2018 0 Comments

gmaster (short for Git Master) is a Git GUI designed to solve 3 key issues that users face: branching is hard to understand, merging is a nightmare and committing changes is tougher than it should.

To solve these 3 key problems, we introduced 3 solutions in gmaster:

  • Natural branch visualization – so understanding branching becomes trivial.
  • Built-in merge tools with semantic superpowers - to remove the pain out of merging.
  • One step commits: to simplify saving changes.

These were the goals we had when we decided to develop it. And these are the key differentiators when you compare gmaster to all the other Git GUIs around.

Repository visualization – it is all about branches

It must be me, but when I draw a branch structure on a whiteboard I never do it vertically. I tend to draw something like this horizontally:

And that's the foundation of the Branch Explorer in gmaster — a comprehensive way for users to understand what is going on in their repos. It turns branching into something obvious.

But, some say that the typical vertical layout in other GUIs is more compact and it is easier to browse the commits. To solve that, we have done a couple of things.

First, is that the Branch Explorer comes with both built-in diff, (in the picture below, it shows the image diff), and commit properties that you can see when you click on the commit:

There is also a popup when I hover over a commit that shows more info:

Second, is that we added a "commit list" view for those people that miss the more traditional visualization:

But, there are a few more things that we added to the Branch Explorer to simplify visualization. My favorite one is "filter relevant commits". For example, look at this:

This is my "p2pcopy" repo history. I can "compact" the graph by collapsing commits that are not the source of a merge, end of a merge, beginning or end of a branch or not tagged:

The graph is now much more compact than before, and it allows me to see more of the repo topology.

Filtering is the other key feature here. I can right-click a branch and say "filter selected and related", as follows:

And then it simplifies the Branch Explorer this way:

Third and finally, it is important to note that all branching and merging operations can be done interactively from the Branch Explorer, such as creating new branches, merging, doing a cherry pick and more:

Believe it or not, one of the challenges we face is that some users struggle to remember to right click nowadays, so we are rethinking how to make all key actions visible.

Built-in diff and merge topped with semantic superpowers

There is another thing that used to annoy me when using other Git GUIs — I install them, and they don't come with a proper side-by-side diff, nor a 3-way merge. I had to buy or download third-party products for that functionality.

We always considered diff and merge to be fundamental for version control. So, in gmaster we include a few tools we developed over the years: a side-by-side diff tool, a 3-way merge tool, and our secret sauce — semantic diff and merge, two game changers.

Let's start with the basics first:

  • Side-by-side diff with Xdiff (text block move detection). It can do awesome things like this:
  • 3-way merge with Xmerge. A proper GUI to handle merges.

Learn more about Xdiff and Xmerge here.

Except for the "moved text fragments" part, there's nothing new under the sun here but, hey, the other Git GUIs don't even include that :-).

Now, as I said before, the true game changer is the semantic technology. What if your diff/merge tool understood C# code? This is what we do, and the results are amazing:

It can "break" the diff to show the methods side-by-side that were moved in the file, as you can see in the previous diff where the lines don't match. But, semantic knows that the Between() method was just moved. (See how the method is indicated with the blue C and the purple M, which stands for Changes and Moved).

Once the C# code is parsed great things can be done, like visually explaining the diff in a schematic rendering:

As I said, we packed our semantic merge tool inside gmaster, but we took it further and went multi-file. For example, look at this:

Yes! It is tracking the GetTimeBetween() method and how it was moved to a different file! Both renamed and modified!

Learn all the gory details about cross-file semantic merging here.

Merge preview

When I merge of a branch, most Git GUIs simply wrap around the Git command line to drive the process. We wanted to do something different based on our previous version control experience. So, we introduced a "preview" separated from the commit view. I launch a merge and go to a specific interface that helps me figure out what is going on. Check out the following screenshot:

See how I get a summary of the files in conflict (just one in this case), and what I should do — diff the contributors, merge them with the merge tool, or just keep one of them and discard the other. You also see the diffs so you can inspect changes made on each side.

Do you see the message on top? The one that reads Code moved between files that needs merge detected. Check what happens when I click it:

I get the full power of the multi-file (or cross-file) semantic merge. The method GetTimeBetween() was moved to a different file, but meanwhile was also modified in the original location. gmaster knows how to merge that. This is unique.

I think one day that all merge tools will build on top of that, but today, gmaster is the only one doing it.

All the details are here.

Easier commits – no index to struggle with

Not all Git users are hardcore experts. Most don't know the internals and struggle with "2 step" commits. And, well, we think they are right. There's enough on their plate without having to wrestle with another tool.

That's why we simplified the commit process as much as we could. You just see the changed files and you commit. That's all. No intermediate step to "add to the index".

As you can see in the screenshot, gmaster simply lists the files that were modified, and all I must do is click Commit.

The built-in side-by-side diff (with semantic power) is also included to simplify the review of the changes before commit.

Recently, based on user feedback, we added a couple of helpers, so you can write better commit comments: the summary + description split and some rulers to control the comment width.

Windows first – more will come

While we have programmed GUIs for OS X and Linux, for years we feel more comfortable in Windows.

That's why we decided to develop the GUI for Windows first. It is built using WPF which we already used while building SemanticMerge and some parts of Plastic.

The goal is to develop versions for OS X and Linux UIs once we get enough traction with the Windows version.

Native Git GUI

As I said above, we built the GUI on top of WPF. We wanted something native, to avoid the downsides of an Electron-based solution (huge memory usage). It means rewriting the GUI in 3 platforms, but we think it is worth the effort. We hope users will too :)

Wrapping up

We built gmaster to help every user become a true Git Master :-). To achieve this, we focused on the following:

  • Helping users truly understand how branching works by introducing the Branch Explorer.
  • Removing the pain out of the merge process with a comprehensive preview and superpowerful merge tools. The merge tools are capable of automating most of the merges, and they simplify the interaction when manual intervention can't be avoided.
  • One step commit, so newcomers don't struggle with the Git index.

Finally, if you feel like learning more about gmaster, here are a few more links:

And, you can always download gmaster from https://gmaster.io/installer.

We develop gmaster, a Git GUI with semantic superpowers. It parses the code to really understand how it was refactored and then diff it and merge it as a human would do, matching methods instead of lines.

If you want to try it, download it from here.

We are also the developers of SemanticMerge and Plastic SCM, a full-featured version control.