Guess default push target

[fcollonval]

Fresh rebase of #412

[fcollonval]

/binder

[github-actions]

👈 Launch a binder JupyterLab on this branch

[fcollonval]

@ianhi This should fix #725

[ianhi]

I don't think it fixed it for me:

[ianhi]

Maybe we should modify this error message to explain to the user why the guessing of the push target failed. Something along the lines of this

Suggested change

	response = {
	"code": 128,
	"message": "fatal: The current branch {} has no upstream branch.".format(
	current_local_branch
	response = {
	"code": 128,
	"message": "The current branch {} has no upstream branch. You have {} remotes so a remote cannot be chosen automatically without having set a pushdefault.".format(
	current_local_branch,
	len(remotes)

[fcollonval]

That error message will be used also for a repository without remote.

So I will not change the error message. But prompt the user to choose from the remote list if it exists. Hence your use case will be covered. What do you think?

[ianhi]

But prompt the user to choose from the remote list if it exist

That is the best solution by far. My suggestion was to make it more clear if there were to be no further frontend changes.

[ianhi]

Will having the option to prompt the user to choose from a remote list run into the same issues as the Git Credentials w.r.t the new modal?

[fcollonval]

@ianhi, do you have multiple remotes? Could you post the push request response for the defunct case?

[ianhi]

I only have one remote on that repo

(jlab-git) ian@pop-os:~/Documents/jupyter/git-expt$ git remote -vv
origin  [email protected]:ianhi/git-expt.git (fetch)
origin  [email protected]:ianhi/git-expt.git (push)

I think this is due to a weird interaction between #630 and existing modal for git push/pull here:

jupyterlab-git/src/commandsAndMenu.ts

Lines 303 to 333 in abfdcf2

	export async function showGitOperationDialog(
	model: IGitExtension,
	operation: Operation
	): Promise<void> {
	const title = `Git ${operation}`;
	let result = await showDialog({
	title: title,
	body: new GitPullPushDialog(model, operation),
	buttons: [Dialog.okButton({ label: 'DISMISS' })]
	});
	let retry = false;
	while (!result.button.accept) {
	const credentials = await showDialog({
	title: 'Git credentials required',
	body: new GitCredentialsForm(
	'Enter credentials for remote repository',
	retry ? 'Incorrect username or password.' : ''
	),
	buttons: [Dialog.cancelButton(), Dialog.okButton({ label: 'OK' })]
	});
	if (!credentials.button.accept) {
	break;
	}
	result = await showDialog({
	title: title,
	body: new GitPullPushDialog(model, operation, credentials.value),
	buttons: [Dialog.okButton({ label: 'DISMISS' })]
	});
	retry = true;

Adding some console.logs shows that when I click off the dialog the await finishes but result.button.accept remains false. Then that same interaction can continue indefinitely due to the while loop

[ianhi]

Ooh actually this predates #630, checking out an arbitrary commit from before that (2f9ad78) I also see this issue.

I think the dialog is being closed due to a jupyterlab problem. See the unmerged jupyterlab/jupyterlab#8438 which stops dialogs from being closed by clicking outside them if they do not have a cancel button.

[ianhi]

I think the solution to #725 is to eliminate the old modal and adapt push/pull to use the new modal + toast notifications. But that could be done separately to this PR?

[fcollonval]

I think the solution to #725 is to eliminate the old modal and adapt push/pull to use the new modal + toast notifications. But that could be done separately to this PR?

Thanks @ianhi for the detailed analysis. At the beginning I hoped to use the new model. But unfortunately it is not based on some global function that emits it. Moreover as the action is executed from a command and not a react component, this makes the switch quite complicated. So I try staying on the not robust actual code.

The ideal code word look like:

waitForCall("Pushing...", model.push, args).catch(error => 
if error due to auth then
  Request credentials
  Re try
else if multiple remotes then
  User needs to pick one
  Re try
)

And so this should be independent of the waiting ui component.

[fcollonval]

As the bug is related to JupyterLab modal handling, it is already present in 0.20. I'll merge this to make the long due release. And we can release the fix when available as release is now easier.

[fcollonval]

@meeseeksdev backport to 0.11.x