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