New Project from Git Repo - failure case



Found an unintuitive result when playing around with the alpha. If you create a new project via the dropdown -> git clone choice (New Project from Git Repo), and:

  • mistype / paste incorrectly the HTTPS link (or point to a nonexistent repo)
  • mistype your authentication details
  • have a time-out for any reason between and the git source (e.g., if the repo you're pointing to is on some local system, not GitHub)

then users:

  1. Sit through the process launch time, as a new project is initialized, and
  2. Get an empty project without the clone you want

I'm not sure what the correct fail-case should be, but my intuition suggests that if the git clone fails, users don't actually want a blank project just sitting there that then has to be deleted. And (AFAIK - if I'm wrong on this, it's the easiest workaround) there's no easy way to clone a repo into a (fresh) project, so users can correct their mistake.

So my suggestions for possible workarounds/changes are:

  1. Exit out of and delete the project if the git clone fails, due to whatever reason, rather than leaving a blank project dangling, or
  2. Run the git/GitHub phase of the clone+initialization first, then launch a project and move the temporary cloned files/directory into it.

Number 2 seems better, because the process could terminate if the clone fails, and then the user never has to sit through the project load screen, which is currently the largest time sink of getting up and running. However, depending on how the back-end security works, it may not be feasible?

If there's other suggestions or options, that's great, but I wanted to point out this edge case (which in using for education will/does happen a lot, because novices are bad at understanding how to reference GitHub and remembering their authentication details).


Thanks for the thorough description and thoughtful suggestions for how to deal with this problem. Improving how we handle url & authentication errors when creating a project from Git was already high on our (long) list of things we want to make better about Cloud - but your note adds some additional clarity and urgency to the task.