Replies: 3 comments
|
I think part of the reason is that it's really trivial to clone a repository to a temporary directory, and can be written with a 3-line script. In general we've also been able to keep this an offline-only tool, and there are some drawbacks to supporting actions that require a connection to the remote (more dependencies, more usage to support, etc.) |
If you don't then the tool will have to. It's not in the tool scope. It would add complexity, then will come feature such as: - "please respect http proxy when dealing with http URL"
And then you implemented a whole factory instead of a DRY tool. I agree cloning first via a script. My point would have been different if the idea was I don't know parsing something and calling a few random URL discovered. But here, you somehow explain you:
|
|
Thanks for the replies. Sure, like I said, as users we can all clone our git repos. I just wanted to understand the scope and the principles better. I agree, it would open up a can of worms like http proxies, supporting providers. |

If you don't then the tool will have to. It's not in the tool scope. It would add complexity, then will come feature such as: - "please respect http proxy when dealing with http URL"
And then you implemented a whole factory instead of a DRY tool.
I agree cloning first via a script.
My point would have been different if the idea was I don't know parsing something and calling a few random URL discovered.
But here, you somehow explain you: