What's New in GitBrowser

We only shipped GitBrowser for Mac earlier this year (after it being an internal tool here at RemObjects for several years), but it has already evolved a lot since. Let's take a look at some of the exciting new features we recently added...

Change Set Analysis

One of my favorite features that recently landed, and frankly one I cannot even believe I lived without, is Change Set Analysis.

These days, I don't just work on my local checkout alone. Between CodeBot and Codex, I often have several agents working on adding new features or improvements at the same time, while also tweaking and reviewing code myself. After a while, I easily end up with 30+ changed files covering different sets of features, all ready to be reviewed and committed. (Yes, I should be using separate branches, see below 😉. But often I don't, because often it's easier not to).

GitBrowser's new Change Set Analysis makes it easy to sort out what's landed, review it, and commit it clean.

Simply right-click in the empty space of your changed files list, and choose "Analyze Changesets with CodeBot". GitBrowser will gather all local changes, and pass them to CodeBot to analyze, and after a few seconds, you get a view like this:

CodeBot has grouped my 20+ changes into distinct groups, and provided me with a succinct description of what each changeset entails. In this case, there's a new "code completion" for the prompt editor (think typing voice=), changes to the history chat compression, and some more changes off-screen.

Clicking on any of the filenames will give you a diff preview via QuickLook.

If I'm feeling confident, I can click "Commit" right there, confirm and/or adjust the pregenerated commit summary, and done. More often than not, instead I'll choose "Stage This" and close the sheet. GitBrowser ill stage the relevanr changes for me – and prefill the commit message – but i can then have a peek at the files, review the changes, and see if i maybe want to include or exclude anyting else form this change, before i commit manually.

In the example shown here, the changes were to several pretty distinct features, so there was no overlap. But the cool thing with Change Set Analysis is that it works even if parts of a single file have changed for Feature A, and others for Feature B. When you tell it to stage (or commit) Feature A, you will see that the file shows in a partially staged state – GitBrowser has committed only the sections that belonged to Feature A, but not the ones for Feature B.

Pretty cool.

Partial Staging or Reverting

GitBrowser has also gotten support for manually staging just parts of a file. Again, this is helpful if, e.g., you made changes to a file that cover distinct features, but also if you maybe have some changes that are ready to commit while others are not, or you have unrelated local changes – e.g., debug logging – that you don't want to commit.

Right-click in the diff view at the bottom right of GitBrowser, and you can now choose to stage (or discard) any individual change (or hunk, as Git calls them).

In this case, I'll discard the change, because importing Foundation is silly when AppKit is already in use. Even Codex doesn't get it right all the time... ;)

If a file is partially staged (showing as [-]), a new toggle at the bottom of the diff view lets you choose which diff to see: previous version vs. staged, or staged vs. unstaged. (If a file is fully staged or fully unstaged, the toggle is disabled – because one of the diffs would be empty. But it still adjusts to show you which view you are looking at.

Double-clicking your file to open an external diff viewer will open a three-way diff (if supported), allowing you to compare the previous version, staged, and unstaged, at the same time (this part is not new).

Worktree Support

I'm somewhat new/late to using worktrees, myself, and you will argue that embracing them more fully would prevent needing Change Set Analysis. And you'd be right, but.

In Git terminology, a Worktree is similar to a branch being checked out to its own separate folder, except that it is not, in that it doesn't require you to have a complete separate clone of the repo, and that Git keeps track and manages your wlorktrees for you. GitBrowser embraces worktrees and makes ot really easy to work with and manage multiple worktrees for your repository.

Personally, I'm not a big branch guy myself. I will use branches (and worktrees) for big, long-running feature work, but I prefer to stay on my main branch for regular development. Hence, Change Set Analysis ;).

Getting started with worktrees in Git Browser is super easy. You can create a new worktree in two ways, from the Branches pop-up in the toolbar

• Open the "Worktree from Branch" submenu, and pick any existing branch.
• Choose "New Worktree..." and pick a name for a new branch, to create a worktree based on your current branch.

Note that you can only create a worktree for a branch that is not currently checked out, and once you have a worktree for a branch, Git will not allow you to switch to that branch on your main checkout or on any nother worktree. GitBrowser will gray our ineligible branches in the menu.

In either case, GitBrowser will ask you for a target folder for your new worktree. It will suggest your main repository folder, suffixed with the branch name, e.g. ./MyApp-develop-coolnewfeature so the new worktree would live next to the orogonal folder – but you can place your new worktree anywhere on disk that you like.

Once a worktree exists, you can work in that folder like you always would. You can commit, you can push, you can merge e.g. your master branch back into the worktree branch, and so on. It behaves like a normal Git checkout. You can even switch branches (which might get confusing if you named your folder after the branch, so I don't recommend it), as long as that branch isn't checked out elsewhere.

Git and GitBrowser keep track of your worktrees, and if you do have any active worktrees, they will show up as child nodes of your repository. They will also show in the branches pop-up in the toolbar.

Your main checkout will show with the solid tree icon, and it represents the main folder of your repository, the actual git clone. Secondary worktrees will show as the hollow tree icon.

Selecting any worktree in the list will allow you to work with that worktree and on that branch in GitBrowser, as if it were a normal checkout (which it is, I guess). You can review your changes, stage and commit, browse history, run available merge scripts, and so on. (Selecting the "solid tree" main checkout is the same as selecting the root node).

The context menu for worktrees provides some additional helpful options. "Compare to" opens your favorite diff viewer for a folder comparison between the two worktrees and any other. It's helpful if you just want to have a quick peek at what's different, or maybe review a change made in the branch compared to the original code.

More interestingly, "Analyze Changes over" allows you to run a full Change Set Analysis (similar to above) between the two branches. Like for local changes, Change Set Analysis will ask CodeBot to have a detailed look at the files that differ between the two worktrees, and give you summaries of the changes in logical groups.

It's super helpful if your co-worker just dumped a branch on you to merge with seven new features that need to be reviewed and approved before they can be merged. Not that that ever happened to me...

Finally, at the bottom of the context menu, there's an option to "Retire" the worktree once you're done with it. Retiring will delete the local folder (but not the branch!), and will unregister it with Git. You should generally not just delete the folder manually, because then Git will not know about it and get confused. But if you did, GitBrowser will detect that, show your worktree as "missing", and give you an option to clean things up.

As a last aside, you might notice the two odd worktrees in the screenshot above, and might find similar one slisted on your system. Worktrees can be checked out to a name branch or a commit, and – unlike with branches, several worktrees can exist for the same commit. The two you see here were created automatically by Codex for background work. It will sometimes do that. You can delete them in either GitBrowser or via Codex's Preferences view, if you are sure they aren't needed anymore.

GitBrowser for Windows

GitBrowser was originally conceived as a Mac app, because I wrote it mainly for myself to use when GitBox died.

Since we shipped it, a lot of people have asked to use it on Windows, so here we are.

GitBrowser was actually built on the same IDE foundation as Fire, so porting it turned out to be a lot easier than expected (or maybe just as expected) – it was basically a weekend side project to get a usable v0. We have done a lot more polishing since, and a lot more is to do, but as of this week's .295 set of builds, a preview build is available for download. Check it out and let us know what you think!

GitBrowser and CodeBot Server

Finally, I want to talk about a new option for connecting GitBrowser to AI.

Right now, GitBrowser uses embedded CodeBot – just like Fire and Water, if in an exposed, much more limited way – for its AI functionality. This means you provide it with your own API key to connect it to the AI provider of your choice, e.g. OpenAI, Claude, or Gemini.

With the upcoming CodeBot for Delphi, which uses our own CodeBot Server backend, you will now be able to connect GitBrowser to your CBS account and your existing CodeBot/Delphi credits for the AI features – no separate sign-up with an AI provider needed. In the back, CBS uses OpenAI's gpt models.