Why hash it, and not just keep the url + branch encoded to some charset that is a valid path, saving rare yet hairy collisions?
Hmm, good point. Originally, I had my program cloned via a git clone that would just clone into a folder of whatever the filename was. Therefore if we had two repositories named MyRepo, it would cause problems. We (my mentor Sebastien aka Dereckson) had done the md5 hash as a way to combat that but I supposed we didn't think of creating a folder using just the name of the url. I think this was back when we might use local repositories. My program can use urls like this: /some/path/to/repo. In which case, you may get different local urls? Thinking about it, it doesn't really make sense. I think this is just one of those scenarios where we thought of a solution and worked and the program evolved in a way where it wasn't necessary anymore. Changing the hash back to charset of a path should be an easy fix.
Speaking of local repositories, another idea was to disable the option to have a local repository as the git url as a safety precaution or something. Should I do away with the local repo feature entirely or should I set a flag and have it be off by default, but allow the user to choose to turn it on?
Will there be a re checkout for a duplicate request? Will the cache of files ever be cleaned?
I did a little test and it looks like if you duplicate the request, the original content doesn't change. So even if it has be remotely changed, the local copy doesn't change. Additionally, when you add a file to the sparse-checkout, the ` git read-tree -mu HEAD ` command only seems to pull the added file but doesn't seem the change the contents of a file that's already in the repo. So right now the only way to get new content is to delete the repository and rerun it. This is a good thing to work on. I'm not sure what you mean by the cache of the files being clean. Can you elaborate on the scenario and I can give you a better answer.
Thanks for your feedback! :)
-- Teresa