Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-encode cwd if path does not exist #1214

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ardislu
Copy link
Contributor

@ardislu ardislu commented Feb 4, 2023

Fixes the case where a folder name is cloned with url-encoded spaces.

Closes #1211

Fixes the case where a folder name is cloned with url-encoded spaces
@github-actions
Copy link

github-actions bot commented Feb 4, 2023

Binder 👈 Launch a binder notebook on branch ardislu/jupyterlab-git/fix-spaces-in-repo-name

Copy link
Member

@fcollonval fcollonval left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand how this can fix the issue. Would you mind providing more explanation?

@ardislu
Copy link
Contributor Author

ardislu commented Feb 8, 2023

If I have a folder with the literal name:

repo%20with%20spaces%20in%20its%20name

jupyterlab-git does not recognize that any git repository exists in this folder (it shows the "You are not currently in a Git repository" page).

This folder is encoded into the Jupyter URL as:

http://localhost:8888/lab/tree/repo%2520with%2520spaces%2520in%2520its%2520name

I believe the problem is that this URL is somehow getting decoded twice (or more) by the time it reaches the git.py file.

The desired value after exactly 1 decode:

repo%20with%20spaces%20in%20its%20name

The actual value (2 or more decodes happening):

repo with spaces in its name

Since the folder /repo with spaces in its name does not exist, jupyterlab-git does not recognize any git repository exists.

I'm unable to identify where/how exactly the URL is getting decoded twice, to fix the root cause. So for this PR I suggest checking if the path exists:

/repo with spaces in its name

And if this path does not exist, try again but with the spaces encoded:

/repo%20with%20spaces%20in%20its%20name

This fix will correctly identify that there is a git repository inside a folder literally named: /repo%20with%20spaces%20in%20its%20name.

Hope that clarifies the problem and the fix.

@fcollonval
Copy link
Member

Thanks for the additional explanation @ardislu

So it means that with this PR if the repository is named repo with spaces in its name it will actually be cloned within a folder named repo%20with%20spaces%20in%20its%20name. Is that correct?

@fcollonval
Copy link
Member

And if you use the git clone command in the terminal, what is happening? Is the folder name with space escaped or not?

@ardislu
Copy link
Contributor Author

ardislu commented Feb 9, 2023

So it means that with this PR if the repository is named repo with spaces in its name it will actually be cloned within a folder named repo%20with%20spaces%20in%20its%20name. Is that correct?

Correct.

And if you use the git clone command in the terminal, what is happening? Is the folder name with space escaped or not?

git clone also clones a folder literally named repo%20with%20spaces%20in%20its%20name.


Full end to end example:

  1. Here's a repo named repo with spaces in its name in Azure DevOps (GitHub does not allow spaces in repo names):

How a repo named "repo with spaces in its name" appears in the Azure DevOps UI

  1. Azure DevOps provides the following URL to clone this repo:
https://ardislu@dev.azure.com/ardislu/ardis.lu/_git/repo%20with%20spaces%20in%20its%20name
  1. Calling:
git clone https://ardislu@dev.azure.com/ardislu/ardis.lu/_git/repo%20with%20spaces%20in%20its%20name

Gives me a folder literally named repo%20with%20spaces%20in%20its%20name. Using the Jupyter UI to clone also gives the same result.

@fcollonval
Copy link
Member

Thanks a lot for the reply.

My fear with the current fix is that it may escape unwanted space. For example if your repository is located at /home/me/a sub folder with spaces/my%20repo, you will escape the spaces in the subfolder. So a safer fix seems to require finding why repo%2520with%2520spaces%2520in%2520its%2520name ends up being decoded twice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Git repositories with spaces in their name are not recognized
2 participants