[Draft] Adding commit hash support.

[hiragram]

Hi. First of all, thank you so much for your great work on Mint!

Description

I want to specify one exact commit rather than branch or tag name in Mintfile.

And I've found this line:

https://github.com/yonaskolb/Mint/blob/6d889541bf3c8935bad858e15dee3937d5cc119c/Sources/MintKit/Mintfile.swift#L41

When I saw this line, I thought Mintfile already support specifying version using commit hash like yonaskolb/Mint@9010ebe but it doesn't work because because git clone -b doesn't support cloning using commit hash.

ref: https://github.com/yonaskolb/Mint/blob/784ecd0d158b25c88e87101977af163fd21cf8ed/Sources/MintKit/Mint.swift#L248

I've experimentally added commit hash support like yonaskolb/Mint@commit:9010ebe on this PR. It's still draft because no tests are added and I haven't understood Mint completely. These changes are very rough but you can review my concept. Do you have any ideas about this?

Questions

• When does this code executed? In my PR, commit hash is specified as yonaskolb/Mint@commit:9010ebe so it conflicts to these lines, but I don't understand when : appeares after @ in current specification or implementation. https://github.com/yonaskolb/Mint/blob/d955d04edddd9ecb0ce6701395c8e740e30bf9d6/Sources/MintKit/PackageReference.swift#L23-L25

• [just curious] Are there any usecases that packageParts.count == 3 becomes true? I don't know when 2 @s appear in one line. https://github.com/yonaskolb/Mint/blob/d955d04edddd9ecb0ce6701395c8e740e30bf9d6/Sources/MintKit/PackageReference.swift#L19-L21

[dchohfi]

hey @hiragram amazing contribution, thank you, are you planning about finishing it? if you need help, I might be able to finish whatever is left. thank you.

[hiragram]

@dchohfi hello. This is still draft and very conceptual. I want to hear what @yonaskolb thinks about this design before I start implementing properly. So I have no more progress than this PR.

[hiragram]

Hi @yonaskolb . Thank you for your review. In your plan, I am worried that branches named develop will be involved. Does it sound good to you? I have no idea how many people will get affected and how much execution will get slower.

I also understood your answers to my questions. In my opinion, it's better to stop using symbols like @ to specify repository and/or revision. If Mintfile is designed like github yonaskolb/Mint commit:9010ebe rather than yonaskolb/Mint@9010ebe, things can get more easier, I think. This is extremely breaking change, but there are no chance to do that after Mint has reached to version 1 . I understand it's not the main subject on this PR. So let me open another issue if you think there is room for discussion.

[yonaskolb]

To mitigate any slowness when using branches, some extra heuristics could be employed:

• checking for explicit common names like master, develop or dev
• assuming that if a string is still 7 or more chars, but doesn't have numbers in it, it must no be a char. That is not sound proof and could lead to false positives, though I believe it's HIGHLY unlikely that a SHA doesn't have a number in it. If that were ever to happen a user could enter a longer sha which would have a number in it In the end, having to clone the whole repo isn't the worst thing anyway.

I agree about @ not being a perfect way to specify a version. It's just been there since the beginning and parsing git@x and ssh://.. came after and complicated things. I recommend opening a new issue for that for discussion

[hiragram]

Got it. I am opening another issue to discuss about re-design of Mintfile. This PR strongly depends on design of Mintfile, so I keep this PR pending until the discussion has completed.

[yonaskolb]

Closing this in favour of #172