Fixes #69 Support for fetching branches, tags and commit hashes and #68 Tag flag is ignored when using url

[dhoer]

Git clone now does a shallow clone to a specific branch (which can be a tag, commit hash or branch name) with default branch of 'master'

[dhoer]

@mobeets I tested this manually, but would like a test case to be added. Do you have a matlab lib repo in mind that would be good test case? Something that has a file added or removed between commits would be easiest to test.

I would like this feature documented, but I don't know where it would go in the readme. Is this something you would be interested in taking care of?

Thanks in advance

[mobeets]

Awesome, this sounds cool. Can you give me an example of how you run this to get different branches/tags/commits? (Do you use the same flag for any of those cases?)

[mobeets]

Ah, I see how it works for branches and tags. How do you specify a certain commit? Do you provide the hash?

Looks good thought. My only thought is that, rather than assuming the default branch name is 'master', it might be better to just call git clone without specifying --branch. Just in case there's some repo out there that doesn't have a branch named master.

Also, as for an example repo, https://github.com/matlab2tikz/matlab2tikz might work. It has multiple branches, tags, and releases. Would that work for what you're going for?

And yeah for sure, I can add it to the readme.

[dhoer]

I made the change requested. I tried your suggestion about using matlab2tikz, but ran into a logic problem that I need some clarification on. When using matlab2tikz, the logic it checks for github.com forces to another path. Is mpm expecting a zip archive as default?

It seems there are two use cases:

• download zip file because it contains generated code that was the output of the build
• download source, because the repo doesn't contain code generated code

Is the above assumption correct?

If so, how do we easily accommodate these scenarios? I can't test my use case, since the repo is public. It would work for a private github repo. Which doesn't feel right. Not sure how to move past this...

Maybe allow for type?
-type zipball - the default - zip archive to be downloaded and unpacked
-type source - to download source

Then remove the github.com portion of that logic and replace with this?

Lastly, zip archives are defaulting to /zipball/master, should that be refactored to handle the tag?

[dhoer]

Looks like github supports downloading zip archives based on tag, branch and hash.
https://github.com/matlab2tikz/matlab2tikz/archive/0.4.7.zip
https://github.com/matlab2tikz/matlab2tikz/archive/develop.zip
https://github.com/matlab2tikz/matlab2tikz/archive/b3c58ec8.zip

I assume this would require defaulting to master, and no longer cloning, which would be a backward breaking changes?

[dhoer]

Ok, so now zipball downloads support tags, commit hashes, and branches as well. I wrote the tests for these use cases.

The problem now is how do I test git shallow clone? I tested it manually against tags, commit hashes, and branches and it looks good.

I think the business logic needs some tweaking.

I propose the following pseudo logic:

if force clone:
    git clone 
else
    test if zipball supported (see https://www.mathworks.com/help/matlab/ref/matlab.net.http.requestmessage.send.html)
    if valid response:
        download zip and unpack
    else 
        git clone 
    end
end

Anyhow, I think this PR should be good to go once the readme is updated.

[mobeets]

Very cool, this looks great! I'll update the readme now.