Zed Editor v1.15.0-pre リリースZed Editor Releases v1.15.0-pre

Zed, the high-performance code editor built in Rust by the team behind the Atom editor and the Tree-sitter parsing library, has published its v1.15.0-pre release. This release">pre-release build centers on how the editor visualizes version-control changes, introducing a configurable diff base that gives developers more control over what counts as a "change" while they work. For teams that rely on Zed's Git integration, the update refines a workflow detail that directly affects code review and everyday editing.

The headline addition is a new git.diff_base setting. It lets developers choose the reference point that Zed uses to compute differences across several parts of the interface. Specifically, the setting governs the editor gutters, the file-status colors, and the output of the git: diff command. Previously these indicators compared the working tree against a single baseline; the new option makes that baseline explicit and switchable.

Two modes are available. In the first, Zed shows uncommitted changes against HEAD, meaning the indicators reflect only edits that have not yet been committed on the current branch. This is the conventional behavior most editors default to, useful for seeing what you have modified since your last commit. In the second mode, Zed shows all current-branch changes against the default branch's merge base. Here the comparison spans everything that differs between the point where your branch diverged and its present state, effectively surfacing the full scope of a feature branch rather than just the latest uncommitted work.

Understanding the distinction requires a note on what a merge base is. In Git, the merge base of two branches is the most recent common ancestor commit they share. When you compare your working branch against that merge base, you see the cumulative set of changes your branch has introduced, including edits that are already committed but not yet merged. That view aligns closely with what a reviewer sees in a pull request, since platforms such as GitHub and GitLab typically compute diffs against a comparable ancestor. By exposing this choice inside the editor's gutters and file colors, Zed appears to be narrowing the gap between local editing and the way changes are ultimately reviewed.

The practical effect is context-dependent. Developers focused on incremental commits may prefer the HEAD baseline, which keeps the gutter noise limited to work in progress. Those building out a larger feature across many commits may find the merge-base view more informative, because it highlights every line the branch touches relative to the mainline. Because it is a setting rather than a hard-coded behavior, the two audiences can each configure Zed to match their preference without a compromise.

Alongside the diff work, the release adds support for dragging files from the project panel. The project panel is Zed's file tree sidebar, and drag support of this kind generally makes it easier to move files, open them in specific split locations, or hand them off to other targets through direct manipulation rather than menu commands. The source excerpt describes the capability in terms of dragging files from the panel, and the exact set of drop destinations is likely detailed in the full release notes.

A few points of context are worth keeping in mind. This is a release">pre-release build, denoted by the -pre suffix on v1.15.0, which means it is intended for early testing ahead of a stable version and may still see adjustments before general availability. Zed ships on a rapid cadence, and the excerpt frames these items as part of "this week's release," consistent with the project's frequent iteration. Users on the stable channel will typically receive such features once they graduate out of the preview track.

More broadly, Git tooling has become a competitive area among modern editors. Established tools like Visual Studio Code, along with editor extensions such as GitLens, have long offered gutter indicators and inline diff views, and dedicated clients continue to refine branch-comparison workflows. Zed's move to make the diff base a first-class, user-selectable setting fits that trend of giving developers finer control over how repository state is represented. For anyone already using Zed's Git features, updating to try the git.diff_base option and the new project-panel dragging is the most direct way to evaluate whether these refinements suit an individual or team workflow.