feat: implement remote management infrastructure, UI components, and state-driven effect handling for repository operations

[angeousta]

Support for managing Git remotes directly from the GitComet UI. It adds the ability to edit an existing remote, change its name, update its fetch and push URLs, and persist those changes through the application state and Git backend. The implementation covers the complete flow from the UI interaction down to the Git command execution, including state management, effects, backend support, and integration tests.

Remote editing UI

A new Edit remote… action is added to the remote context menu, allowing users to open an editing popover directly from an existing remote. The edit flow exposes the remote name and URL information and allows users to modify the configuration without having to remove and recreate the remote.

The edit form also handles the relationship between fetch and push URLs. When the user chooses to keep the push URL synchronized with the fetch URL, the new fetch URL is automatically used for both values. Otherwise, the push URL can be edited independently. This makes it possible to support both the common single-URL setup and remotes that intentionally use different fetch and push endpoints.

Remote rename support

The PR adds a dedicated RenameRemote message to the state layer, carrying the repository ID, the previous remote name, and the new name. The reducer/effect flow then translates this state change into the corresponding remote operation.

When submitting an edit, the implementation first determines whether the remote name has actually changed. If it has, a rename operation is dispatched before applying the updated URL configuration. This keeps remote identity changes explicit in the state/effect system while allowing the complete edit operation to be handled from a single UI flow.

Git backend support

Remote rename functionality is also wired through the Git backend layer, extending the existing remote management API with rename_remote_with_output. This allows the higher-level state and UI layers to use the same command/effect architecture already used for other remote operations.

The implementation is accompanied by integration coverage that verifies that a remote can be renamed successfully, that the resulting remote list contains the new name, and that subsequent operations continue to work using the renamed remote. The test also verifies the command exit status before checking the resulting repository state.

URL and remote configuration handling

The changes extend the remote-management flow beyond simply changing a display value. Remote configuration is treated as an actual Git operation, ensuring that changes made through the UI are propagated to the underlying repository.

The edit flow reads the updated remote name and fetch URL from the corresponding inputs, determines the appropriate push URL based on the synchronization setting, and then applies the required operations. This provides a consistent path for modifying both remote metadata and its associated URLs.

State and effects

The new functionality is integrated into the existing state-driven architecture rather than performing Git operations directly from the UI. A RenameRemote message is emitted by the UI layer, handled by the reducer/effect system, and ultimately translated into the backend operation. This keeps remote management consistent with the application's existing command and effect patterns.

Testing

Integration coverage has been expanded to validate the remote rename lifecycle, including:

• Renaming an existing remote from its original name to a new name.
• Verifying that the Git operation succeeds with an exit code of 0.
• Reloading/listing the repository remotes after the operation.
• Confirming that the renamed remote is present under the expected name.
• Continuing to use the renamed remote for subsequent remote-management operations.

Additional UI-related test coverage is included alongside the remote popover and related view components, helping ensure that the new editing flow is integrated into the existing GitComet UI architecture.

[Havunen]

We already have edit fetch URL and edit push URL for remote actions.

Lets change this to simply "Rename remote", same time we could remove "..." suffix from the options as they were removed else where as well.

embedding username in the URL does not make sense IMO. User can just add the URL as is, now it is incorrect anyway.

[angeousta]

embedding username in the URL does not make sense IMO

I have multiple git accounts and whenever i press "push" it spawns a git gui asking me "which account?" so a easy way to set an username is pretty handy to me

[Havunen]

Yeah, I communicated badly what I meant. I meant one can just enter the URL with username embedded and we dont need another input field for it. Or did I miss something?

[angeousta]

You are right, it could be a nice improvement, but it is not 100% necessary