806a72c540
## Context I have a project with a nested git repo inside a parent repo (separate `.git` directory, not a submodule). The title bar shows the parent's branch instead of the nested repo's own branch. The issue is in `get_repository_for_worktree()` — it iterates `git_store.repositories()` (an `FxHashMap`) and returns the first `starts_with` match. Both the parent and nested repo match, and whichever one FxHashMap iterates first wins. There's no reason it should be one or the other. The fix already exists elsewhere in the codebase — `GitStore::repository_and_path_for_project_path()` at `git_store.rs:1826` uses `.max_by_key()` to pick the most specific (longest path) match. This PR applies the same approach to three functions that have the same problem: - `TitleBar::get_repository_for_worktree()` — branch display in title bar - `resolve_active_repository()` in `git_ui` — repository selection for the git panel - `get_branch_for_worktree()` in `recent_projects` — branch display in the project switcher Two other locations use a similar `starts_with` pattern (`effective_active_worktree()` in `title_bar.rs` and worktree selection in `recent_projects.rs`) but those iterate worktrees against a single known repo, not repos against a worktree — so first-match and longest-match give the same result. Left those unchanged. Closes #7566 ## How to Review All three changes are the same transformation: first-match loop (or `.find()`) → `.filter().max_by_key()` on path length. The reference is at `crates/project/src/git_store.rs:1826`. The primary fix is `get_repository_for_worktree()` in `title_bar.rs`. The other two are the same pattern. One difference from the reference: I used `.as_os_str().len()` instead of `.clone()` for the `max_by_key` key — avoids cloning an `Arc<Path>` per comparison. Among prefix-related paths (which is all that passes the filter), the longer path is always the more specific match, so length comparison is equivalent. `title_bar` has no existing test infrastructure. Happy to add a test if you'd like — the setup would follow the pattern in `test_git_traversal_with_nested_repos` (`crates/project/tests/integration/git_store.rs`). ``` cargo test -p title_bar -p git_ui -p recent_projects ./script/clippy ``` ## Self-Review Checklist - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed branch picker showing parent repository's branch instead of the nested repository's branch when working in submodules or nested git repos. --------- Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com> Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking issue)
Developing Zed
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.