git: Check push config before falling back to branch remote

[errmayank]

Closes #26649

Release Notes:

• Git will now check pushRemote and pushDefault configurations before falling back to branch remote

[cole-miller]

Thanks! According to the docs it seems like we should be able to use git rev-parse @{push} to get the information about where git push should be directed without running git config multiple times--would you be interested in revising this to use that approach?

[errmayank]

@cole-miller seems like we could use:

git rev-parse --abbrev-ref @{push}

But it requires remote tracking set up for that branch, so it won't work for new branches being pushed for the first time. Wdyt?

[cole-miller]

It's okay if we don't select a remote automatically when the branch has no upstream and there's no git configuration indicating where it should be pushed--we have a fallback to open a picker for this situation (if that remotes function returns several remotes), right? We just need to make sure that git rev-parse @{push} honors that pushRemote config option.

[errmayank]

We just need to make sure that git rev-parse @{push} honors that pushRemote config option.

@cole-miller yeah, looks like it does. It goes in this order:

1. branch.<BRANCH_NAME>.pushRemote
2. remote.pushDefault
3. branch.<BRANCH_NAME>.remote

Here's a screenshot from my tests

Note that my push.default is set to current here. With the default simple mode, rev-parse fails whenever the priority determined push remote differs from branch.<BRANCH_NAME>.remote which triggers Zed to fallback to the remote picker showing fork and origin as options in this case.

Here's when push.default is set to simple

[cole-miller]

Thanks for the information! I think it makes sense that we'd honor push.default here, so we act the same way as if you did git push at the command line (except that we show a picker instead of just erroring if you're in simple mode and a remote couldn't be determined). Are there any other issues with using @{push}?

The other thing is that I think we should separate out a GitRepository method for this, since we shouldn't do git rev-parse @{push} for all calls to GitRepository::remotes (e.g. if you do git: fetch from we want to show a list of all remotes regardless of the current branch/push config). Could you implement that?

[errmayank]

Are there any other issues with using @{push}?

Nope, I think that's all.

The other thing is that I think we should separate out a GitRepository method for this, since we shouldn't do git rev-parse @{push} for all calls to GitRepository::remotes (e.g. if you do git: fetch from we want to show a list of all remotes regardless of the current branch/push config). Could you implement that?

Makes sense, I've updated it but instead of creating a separate function I added a RemoteOperationKind enum which I think makes it a bit cleaner, let me know what you think.

[cole-miller]

Hmm, I think maybe a better structure would be

• GitRepository::get_all_remotes which always returns the full list
• GitRepository::get_push_remote(branch: String) that looks at @{push} (edit: or maybe the-branch@{push} to make it not depend on checking out the branch first)
• GitRepository::get_branch_remote(branch: String) that looks at branch.{}.remote

And then push the fallback to "get all remotes" to the callers--how does that sound?