MeGit: EGit as a standalone desktop application

EGit without the IDE around it

The README opens with the observation that motivated the project, and it is a good one. Looking for a powerful, yet easy-to-use, fully open-source user interface for git, there are plenty of options, and one of the favourites is EGit. However, EGit is actually a plug-in for Eclipse rather than a standalone tool, such as GitKraken. Nevertheless, even in projects where the team actually uses other editors or IDEs than Eclipse, they often found themselves firing up an Eclipse IDE with EGit just to handle more complex git branch operations, for analysing the git history, and so on.

The question the project asks itself is worth quoting, because it is the whole design. Wouldn't EGit be a great git standalone tool if it would be, well, an actual standalone tool?

The answer is MeGit, described as a minimal standalone application that contains just enough to run EGit conveniently.

That word minimal is load-bearing. MeGit is not a fork of EGit with new features, and it is not a reimplementation of any of it. It is EGit, packaged with the smallest Eclipse runtime that can host it, so that the expensive part, starting an IDE, disappears.

The licence is EPL-2.0, the primary language is Java, the default branch is master, and the repository is organised as three Maven modules, com.eclipsesource.megit.parent, com.eclipsesource.megit.plugin and com.eclipsesource.megit.product, alongside a doc directory with the screenshot. The last push was on 2026-06-16.

The feature list is EGit's, and the README says so

The Features section opens by saying that EGit, and hence MeGit, provides tons of features, and then lists them.

There is nice visualization of the git history making it easy to keep a good overview when analyzing, merging or rebasing branches, cherry-picking commits and changing the git history. There is interactive rebasing support and an easy-to-use git staging view. There is support for Gerrit and Github, support for GitFlow operations, and much more.

Then the sentence that tells you where to look: please refer to the EGit user guide to learn more.

So MeGit's documentation strategy is delegation. The feature list is short enough to give you the shape of the tool and the user guide link gives you the detail, and that is a sensible division when the feature set is inherited wholesale from another project rather than designed here.

It does mean something specific for an evaluator. You are not evaluating a new Git client, you are evaluating how well EGit's feature set has been packaged for people who do not want Eclipse. The question to ask is not whether MeGit has interactive rebasing, since it does, but whether launching an Eclipse perspective is acceptable as the price.

For a team already inside Eclipse, MeGit offers little. For a team whose editor is something else, and who still found themselves opening an IDE for the occasional branch operation, that is exactly the gap it fills.

Installing is one archive and one executable

The Installing section is short. Download the archive for your operating system from the releases, unpack the archive and run the `megit` or `megit.exe`. You'll need to select a workspace location to store your metadata.

That is the entire procedure, and the last sentence is the part that tells you what kind of application this is. There is a workspace, and the workspace holds metadata, because an Eclipse application keeps its state somewhere and asks where on first launch.

Then the Java requirement, which is unusually forgiving. MeGit requires Java 21, but ships with a Java runtime environment.

That is a deliberate trade-off in the other direction. Bundling a runtime means the download is bigger and the application carries its own JVM rather than using the one on your machine, but it means you do not have to install or configure Java, and you cannot be broken by a system JVM upgrade. For a tool that people download to do one job, that is usually the right call.

The metadata in the workspace is where MeGit keeps its own state, and since the repositories themselves are added directly rather than imported as Eclipse projects, that metadata is small. The next section explains what that means in practice.

No Eclipse projects, just the repositories you care about

The README is explicit about what MeGit does not add. MeGit intends to make it easy to just use EGit. It hence doesn't add any functionality itself, but only builds EGit as a standalone application with the minimal dependencies. Thus, start up should be fast. Just open MeGit and add the git repositories you care about. There is no need to import them as Eclipse projects. Just use the EGit perspective and directly handle your git tasks on the imported git repositories.

Three consequences follow from that paragraph.

The first is startup time. An Eclipse IDE spends most of its launch on starting the workbench and the bundles it has been given, and a minimal runtime with only EGit in it has far less to start. The README's claim that start up should be fast is a consequence of the packaging decision rather than an optimisation.

The second is that you get the EGit perspective, which is what makes this recognisable as EGit rather than a new client. You are learning EGit's menus and views, and the documentation link in the README is the documentation for them.

The third is that the repositories are added as repositories, not as Eclipse projects. You are not getting a Java IDE with a Git view, you are getting a Git tool with an Eclipse shell around it. For the use case the README describes, handling more complex git branch operations and analysing git history, that is the right way round.

The project badges reinforce the framing. They mark it as a product and as a feature complete project in the EclipseSource classification scheme, alongside a Java CI with Maven badge.

Building it means running one Maven command

The build instructions assume Maven is installed, and then give two commands:

cd com.eclipsesource.megit.parent
mvn clean install

The runnable product will be available in `com.eclipsesource.megit.product/target` for your platform. Just extract the archive and run `megit`.

The three module names map onto that. The parent module holds the shared build configuration, the plugin module holds the EGit-based application code, and the product module produces the packaged, runnable artefact. That last part is why the output is a platform-specific archive rather than a jar: a desktop product has to be assembled with its launcher, its configuration and its bundled runtime.

The Java CI with Maven badge points at a build workflow, so the same path is exercised on every change.

For someone who wants to build rather than download, the practical requirements are a JDK, Maven and some patience, because the product build repackages a Java runtime. The output then matches the downloaded archive: extract it, run the executable, pick a workspace.

The version number tells you which EGit you are getting

The Changelog is the most informative document in the repository, because every release is named after the EGit release it is built from. That makes the version number a proxy for the feature set, which is a rare and useful property in a packaging project.

The early releases track EGit's own six-month cadence. 0.0.1 is the initial release based on Eclipse EGit 2020-12, and 0.0.2 is also based on EGit 2020-12 but adds the Git perspective as default and dark theme by default, and minimizes the editor area by default. 0.0.3 moves to EGit 2021-03, 0.0.4 to 2021-09, 0.1.0 to 2021-12, 0.2.0 to 2022-06, 0.3.0 to 2022-12, 0.4.0 to 2023-06, 0.5.0 to 2023-09, 0.6.0 to 2023-12, 0.7.0 to 2024-06, 0.8.0 to 2024-12, 0.9.0 to 2025-06, 0.10.0 to 2025-12 and 0.11.0 to EGit 2026-03.

Two releases added something of their own rather than only tracking upstream. 0.5.0 added Git LFS support, and 0.7.0 added org.eclipse.tm4e for generic syntax highlighting, which is the TextMate-style engine Eclipse uses for generic syntax highlighting.

Two others changed how the application is delivered, and they are the packaging decisions the project exists to make. 0.6.0 packaged the JVM with the product, which is what removed the separate Java prerequisite. And 0.8.0 switched to Java 21, which moved the runtime floor.

So the recent releases, 0.9.0 from 2025-06 tagged on 2025-07-07, 0.10.0 from 2025-12 tagged on 2025-12-27 and 0.11.0 from 2026-03 tagged on 2026-04-28, are pure EGit updates on a six-month clock.

EPL-2.0, a six-month release train, and one obvious limit

The licence is EPL-2.0, the Eclipse Public License, which is the same licence EGit itself carries. That is a reasonable pairing for a project that redistributes Eclipse components, and it is worth knowing about if you intend to distribute MeGit inside another product, because the EPL has file-level copyleft obligations that MIT or Apache do not.

The release history is regular and predictable, with one release per EGit cycle, which means a user who wants the current EGit features has a build that matches them, and a user who prefers stability has one that is a few months behind. Both are reasonable positions and the project supports both.

The obvious limit is the one the README itself names. Every feature arrives with EGit, on EGit's schedule, with EGit's conventions and EGit's Eclipse perspective. There is no native alternative to the interactive rebase, no way to use a different Git UI, and no path to a MeGit that is not Eclipse underneath. If you are looking for a Git client that is independent of the Eclipse platform, MeGit is by construction the opposite of that.

The other limit is the one that comes with any packaged runtime. Because the application ships its own JVM, you are choosing to run a specific Java version inside MeGit regardless of what else is on the machine, which is convenient for isolation and slightly awkward for anyone with a policy about Java versions or a security scanner that flags bundled runtimes.

Both of those are known costs of the design rather than defects, and for the specific person the README describes, someone who already opens Eclipse for git work, the exchange is clearly favourable.

Editorial conclusion

MeGit fits a developer who wants EGit specifically, on a machine with no Eclipse and no appetite for an IDE, and who values the interactive rebase and the history visualisation enough to accept an Eclipse look and feel without Eclipse. It is the wrong choice if you want a client that is not tied to the Eclipse platform, because every feature arrives with EGit's release cycle and its own conventions, and the wrong choice if you need the app to be a single modern binary with no Eclipse perspective underneath. Verify first which EGit release the build you are downloading corresponds to, since the version number encodes it, that your platform has an archive published for it, and that the bundled runtime is acceptable to you in your environment.

Frequently asked questions

Official sources

1. eclipsesource/megit on GitHub
2. Issues
3. License: EPL-2.0
4. README
5. Releases