git_ui: Move git_graph into git_ui

[GoldStrikeArch]

cc @Anthony-Eid

Why

This is the first step in moving the Git Graph work into the Git UI crate before continuing with follow-up refactors and feature work. The goal is for Git UI components and shared Git UI helpers to live in one crate, so future changes to the Git Graph can reuse existing git_ui code instead of duplicating it.

This PR is not only a filesystem move. While moving git_graph into git_ui, a few small dependency and helper boundaries had to change:

• git_graph and git_ui both needed the same remote parsing and commit tooltip construction behavior, so those pieces are now shared from git_ui.
• git_graph previously depended on project_panel to resolve file-history actions from the project panel selection. After moving git_graph into git_ui, keeping that dependency would create an undesirable git_ui -> project_panel relationship. The project-panel-specific action forwarding now lives in project_panel, and calls into exported git_ui::git_graph helpers instead.
• git_graph initialization now happens through git_ui::init, so downstream crates only need to initialize git_ui.

This prepares the codebase for the next planned PRs: splitting the large git_graph.rs implementation into smaller pieces, then adding Git Graph features such as keeping the main branch lane at index 0.

License removal

The removed crates/git_graph/LICENSE-GPL file was a symlink to the repository root LICENSE-GPL. The moved code is now inside git_ui, which is also licensed as GPL-3.0-or-later and has its own LICENSE-GPL symlink to the same root license file. The code did not move to a differently licensed crate; it remains covered by the same GPL license.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content is consistent with the UI/UX checklist
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• N/A

[GoldStrikeArch]

@Anthony-Eid Looks like after merging a new main branch the tests are broken 🤔

I will take a look and update the branch

update:
should be good now

[ChristopherBiscardi]

These refactoring PRs need some more explanation if you want people to be able to review them. For example, in this PR you removed the GPL license, there are sections of code that were removed, as well as function calls that were changed to other signatures and calls. It isn't clear to me that functions that were abstracted here do the same thing as the original code, such as git_remote_for_repository.

This PR description doesn't include any context for why the refactoring is being done, and I had to go chat with Anthony to find out.

In the future when executing any refactorings like this, please take it one piece at a time in PRs and don't include the addition of logical refactors with large non-logic-related changes like moving files around.

[ChristopherBiscardi]

Also the build failing earlier makes me wonder if you ran the build locally before submitting the PR, which makes me even more suspect of whether some of the logical changes and new functions were adequately checked before the PR was submitted.

[GoldStrikeArch]

@ChristopherBiscardi

Also the build failing earlier makes me wonder if you ran the build locally before submitting the PR

Yes, I did run it locally but the PR was opened ~1 week ago and after merging a new main it failed (as before merging a new main there were merge conflicts)

For example, in this PR you removed the GPL license

The whole git_graph folder was nuked out, so the license is gone as well as it was in that folder

there are sections of code that were removed, as well as function calls that were changed to other signatures and calls.

Yeah, that was a part of the moving things into git_ui (we also were on a pairing session with Anthony, so this part was "aligned verbally") as otherwise code would be somewhat duplicated

In the future when executing any refactorings like this, please take it one piece at a time in PRs and don't include the addition of logical refactors with large non-logic-related changes like moving files around.

Noted. I can put the description and which things were refactored code-wise in this PR as well, wdyt? It will make the review easier I guess but after some thinking: does any "non Zed team member" review really "counts" 😅 ?

[ChristopherBiscardi]

Yes, I did run it locally but the PR was opened ~1 week ago and after merging a new main it failed (as before merging a new main there were merge conflicts)

Yes, it is expected that a PR passes tests after merging main. We can not review or merge it otherwise.

The whole git_graph folder was nuked out, so the license is gone as well as it was in that folder

Yes, and this should be mentioned in the PR description, along with an explanation of why the code that was previously covered under the removed license is compatible with where it was moved to.

after some thinking: does any "non Zed team member" review really "counts" 😅 ?

Not sure what you mean by this, please expand.

[GoldStrikeArch]

@ChristopherBiscardi

I updated the PR description, so it should now have an explanation "why" this PR exists.

along with an explanation of why the code that was previously covered under the removed license is compatible with where it was moved to.

I am not sure that I follow this. The deleted license file was a symlink to the actual license, so the actual license is still there and git_ui is using the same symlink, so the code didn't "change it's license" after moving to another folder. Are we on the same page with this?

Not sure what you mean by this, please expand.

So, how I see this whole situation (Please bear in mind that I might look at this from the wrong angle!):

• I had a pair session with Anthony and he was aware of the changes and the context. The actual context is that I want to add some features to git graph (and again, Anthony knows about "what features", "why it is needed", etc) but before that (from my perspective) it was beneficial to refactor the git_graph.rs a bit (as the file is big IMO and adding even more stuff into it doesn't look like a good idea), and for that I created this PR. This PR now will be rebased after merging the current one (that was the "new plan" during our pair session) as Anthony wanted to move git_graph into git_ui, so all git UI components and related stuff would be in one crate (IIRC that was the idea). And because we couldn't do it during the pair session I said that "sure, I can do it in a separate PR" and hence we have this PR. So, we suppose to have this "series of PRs" -> move git_graph into git_ui (we are here) -> refactor the big git_graph.rs file on smaller pieces (2-3 PRs) -> then add new features (like having the "main" branch always on the left at index 0, as right now it can be at any index and so on. And again, Anthony is aware of it)
• And passing all of that in PR description was kinda "against the whole point" (to iterate quick on it) but as now someone other than Anthony (Zed staff member with the whole context on it) is looking on it it makes sense to put all of that into a formal description "why", "what", "where" (which I did)