Meld is a GTK three-way merge tool that runs straight from a checkout

You can run Meld before you build it

The Running section of the README starts with a point that is unusual for a project of this size. You do not need to build Meld in order to run it, and it can be run directly from the source directory.

$ bin/meld

That is a real convenience for two different audiences. For a user evaluating the tool, it removes the Meson and Ninja steps from the first encounter. For a contributor, it is the whole development loop, because the Developing section repeats it: from a git checkout, just run bin/meld, having installed everything listed in the Requirements section along with the GLib development tools for glib-compile-resources.

There is a bin/ directory in the repository, and it is not a compiled output, it is a script. The ruff configuration in pyproject.toml makes that explicit, since the lint config extends to include the extensionless Python scripts bin/meld and maint so that a bare ruff check covers the same files as the pre-commit hook.

The same idea is carried into the containerised workflow. Meld supports development using Flatpak via GNOME Builder, and the README gives the exact instruction: at the Builder Clone dialog, enter the GitLab URL, and the default build and run development flow using Flatpak should work. For a project with a heavy native dependency tree, having the packaging system as a supported development path is a meaningful convenience rather than a detail.

There is also a meson_shebang_normalisation.py at the repository root, which is the kind of small build-hygiene script that shows a project paying attention to how its scripts are packaged.

Two-way and three-way comparison, files and directories, five version control systems

The scope is stated in the opening paragraph. Meld is a visual diff and merge tool targeted at developers, it helps you compare files, directories and version controlled projects, it provides two- and three-way comparison of both files and directories, and it supports many version control systems including Git, Mercurial, Bazaar, CVS and Subversion.

The three-way comparison is the feature that separates a merge tool from a diff viewer, and it is worth being precise about what it is for. A two-way comparison answers what changed between two files. A three-way comparison answers what changed on your branch relative to a common ancestor, against a file you are trying to merge into it, and the interesting part is that the result is not a line-by-line diff, it is a merge you can edit before you commit it. The stated purpose is to help you review code changes, understand patches, and make merge conflicts slightly less painful.

Directory comparison is the other half. Comparing two directory trees and seeing which files differ, which were added and which were removed is a different task from comparing two files, and supporting it for both the two-way and three-way case is what makes Meld usable on a project rather than a snippet.

The version control list is broader than you might expect from a modern project. Git is the obvious one, but Mercurial, Bazaar, CVS and Subversion are all there, and Bazaar and CVS in particular are close to historical. That breadth is a design choice rather than nostalgia, and it is the reason the alternative worth weighing is not another GUI diff tool but the version control system itself.

Meson builds it, meson-python packages it

The build instructions are three commands, and they are the standard Meson flow.

$ meson setup _build
$ cd _build
$ ninja

$ ninja install

The first block configures a build directory and compiles it, and the second installs Meld system-wide.

The packaging layer is where the interesting detail is. The pyproject.toml declares a build backend of mesonpy and pins the build requirements to meson-python 0.20.0 and meson 1.12.0, which means the project is installable as a Python distribution even though the build underneath is Meson and Ninja. The setup is configured with -Dis_wheel=true in the meson-python arguments, so the wheel path is enabled.

The project metadata is careful in a way that suggests a healthy packaging process. The name is Meld, the version is dynamic and taken from the build, the licence is read from the COPYING file rather than hard-coded as a string, and the classifiers list Development Status 5 - Production/Stable, the X11 GTK environment, audiences of developers and system administrators, and the GPLv2+ licence identifier.

The build requirements list Meson 1.11, Ninja, gettext and GLib 2.66 with its development utilities such as glib-compile-schemas, and the pyproject pins Meson slightly higher at 1.12.0. The gettext dependency is visible in the tree as a gettext/ directory and a po/ directory, which is where the translations live.

The dependency stack, not the app, is the install cost

The Requirements section is the part to read before you install anything. Meld needs Python 3.10, pycairo, which is described as the Python 3 bindings for cairo without the GObject layer, PyGObject 3.38, and gsettings-desktop-schemas.

On top of that sit the packages with GObject introspection: GLib 2.66, Pango, PangoCairo, GTK+ 3.24 and GtkSourceView 4.0.

That is a real stack, and it explains the packaging strategy. On a Linux desktop running GNOME or another GTK environment, most of it is already present, and the remaining pieces come from the distribution's package manager. On a system that is not a GTK system, this is the part that makes Meld a heavy install, and it is the honest reason the project tells Unix users to get it from their distribution package manager or from Flathub rather than from a tarball.

The GtkSourceView dependency is worth calling out for what it implies about the interface. GtkSourceView is the syntax-highlighting text widget behind code editors in the GTK world, and using it is what lets Meld render source files with the same colouring as an editor rather than as plain text. That is a small implementation decision with a large effect on whether a diff view is comfortable to read for an hour.

The Python requirement is 3.10, enforced in pyproject.toml as requires-python, and the classifiers mark Python 3 only. The dependency list in pyproject.toml is empty, which is not an oversight: the runtime dependencies are the native stack above, installed by the system, and the packaging is by way of meson-python rather than pip.

Four ways to install it, and one place to file bugs

The install options are listed by platform, and they reflect how different each platform's packaging conventions are.

Unix users should get Meld from their distribution package manager, or from Flathub. Windows users should download the provided MSIs on the Meld home page, which is at meld.app. OSX users can install Meld using Homebrew, or Macports, Fink and similar, and there are also unofficial native builds available from the Meld for OSX project.

The Windows path has a build counterpart in the repository. There is a windows/ directory, and the README says that for building a Windows version the .gitlab-ci.yml script is the most reliable reference, with the mingw-dist section named specifically. That is the standard GNOME practice of letting the CI definition be the specification for cross-platform builds, and it means the MSIs and the source tree cannot drift apart silently.

The development and support structure is equally GNOME-shaped, and it is the one thing a reader should note before filing anything. Meld uses GNOME's GitLab to track bugs, and user questions and development discussions happen on the Meld mailing list. Issues live at the GitLab issue tracker, the support forum is a tag on discourse.gnome.org, and the wiki is in the GitLab project. The GitHub repository this article is reading is described in its own description as a read-only mirror of the GitLab project.

That is a genuine practical difference for anyone who would otherwise assume GitHub issues are the support channel. A bug filed on a read-only mirror goes nowhere, and the README says new contributors are always welcome even though the development team is small.

GPL-2.0 or later, with a small team and a strict pre-commit

The licence is GPL v2 or later, stated in the README, recorded in pyproject.toml as the license file COPYING, and reflected in the classifier as GNU General Public License v2 or later. The repository has a COPYING file at the root, and this is a licensing fact rather than legal advice.

The maintenance picture is healthy for a project of this age. The repository is not archived, the default branch is main, and the last push was on 2026-10-13. There are no GitHub releases because the releases live on the GNOME GitLab project, and the pyproject points at the GNOME releases URL for downloads, which is where a user would look for a versioned artefact.

The development tooling is strict for a project that started as a small utility. The dependency groups pin ruff at 0.16, pre-commit at 4.6, pytest at 9.1 and pytest-mock at 3.15, and the ruff configuration is commented to explain that the extensionless scripts are included so that a bare ruff check covers the same files as the pre-commit hook. There is a .pre-commit-config.yaml at the root and a .editorconfig. The test directory is a top-level entry, and pytest is run through it.

The tree also carries the usual GNOME packaging furniture, with meson.build and meson_options.txt, build-aux/, a po/ directory for translations, a meld.doap file for the app metadata format, a NEWS file, help/ for the user documentation, and data/ for the icons and desktop files.

What the project does not have is a large team. The README says the development team is small and that new contributors are always welcome, and the pyproject lists a single maintainer, Kai Willadsen, with an email address in the maintainers field.

Editorial conclusion

Meld fits a developer or system administrator who reviews patches and untangles merge conflicts in a graphical interface, especially across several version control systems at once, and who would rather not install a native client to look at a diff. It does not fit a large-scale merge workflow that needs a web review tool, and it does not fit a machine without the GTK and PyGObject stack, which is the bulk of the installation cost. Before adopting it, run bin/meld from a checkout on a machine with the requirements installed, and check the support forum on discourse.gnome.org, because the issue tracker and the user discussion both live on GNOME infrastructure rather than on GitHub.

Frequently asked questions

Official sources

1. GNOME/meld on GitHub
2. Issues
3. License: GPL-2.0
4. Project website
5. README