Push Remote Branch Based on Git Config

[jhamet93]

Currently, a user needs to set the upstream tracking branch explicitly before being allowed to push. However, there exist configuration options that can be set in the git configuration that automatically infers the remote branch to push to.

This change takes those options into account to not fail git push if the configuration options are present. This helps open up the workflow for less experienced git users to be able to perform the actions in their workflow strictly via the extension with no intervention needed in the CLI.

[fcollonval]

@jhamet93 thx for working on this. Could you please add unit tests for this?

[fcollonval]

I rebooted this PR with the following behavior:

If the branch has no upstream:

• Use the remote.pushdefault to determine on which remote to push
• Else if there is only one remote defined, use it
• Else if there are multiple or no remotes, raises an error

Some side actions:

• Adding remote was not asynchronous => this corrects it
• The configuration parameters are filtered in the handler and not in the Git object. So that the server can internally request parameters that are not visible by the frontend.
• If the remote can not be determined, the list of remotes is returned with the error (empty list if no remote, or list of remotes) => this will allow to prompt the user to pick one up or to tell him to add a remote (following PR once Provide UI feedback during Git command execution #630 is merged as it has implication on the handling of push request in the frontend).

[ianhi]

Does it make sense to instead use git remote -v show here? As some future proofing of this function in case it is ever used to determine URLs or do something with determining fetch vs push urls?
For me git remote show:

origin
upstream

vs git remote -v show:

origin	[email protected]:ianhi/jupyterlab-git.git (fetch)
origin	[email protected]:ianhi/jupyterlab-git.git (push)
upstream	[email protected]:jupyterlab/jupyterlab-git.git (fetch)
upstream	[email protected]:jupyterlab/jupyterlab-git.git (push)

[fcollonval]

For now I'll stick to current behavior as there is no feature requiring more information.

[fcollonval]

Thanks @ianhi for looking into this

[ianhi]

@fcollonval if I were to more fully review this could that qualify as adequate for merging? This is a great change that I would love to see in the extension.

FWIW I currently seem to have achieved stronger permissions by being added to jupyterlab-triage:

but I don't know if that was intended to give me those powers.

[fcollonval]

Hey @ianhi thank you for your time. Yes definitely if you could review this, that will be great.

[ianhi]

Yes definitely if you could review this, that will be great.

Are there any guidelines for what is involved in doing that? I certainly should check to make sure it does not break anything or doing anything terribly misguided - but beyond that anything specific?

[fcollonval]

Are there any guidelines for what is involved in doing that? I certainly should check to make sure it does not break anything or doing anything terribly misguided - but beyond that anything specific?

I usually do the following:

• Check that the JupyterLab code format rules is followed.
• check that the code is understandable
• check locally it works as much as possible
• suggest code simplification if needed

[ianhi]

@fcollonval I think that there are non-trivial conflicts following the merge of #691 which also affected the usage of the remote determining commands. Are you able to fix them? If not I can as I definitely feel a little guilty for having caused of these conflicts...

[ianhi]

Bump of this now that #630 was merged

[liamraemclauchlan]

Would love this to be approved and merged 👍

[fcollonval]

Superseeded by #721