Allow to make package from specific upstream tag

[creekorful]

This new flag allow checkout & usage of a specific git tag.

The behaviour is different from using the git_revision flag, since we will force the tag being used.
Using the tag approach is more convenient than using git_revision in the case of multiple tag being used for the same revision.

I was packaging the github.com/viant/afs library, and dh-make-golang has failed, because of wrongly named tag. The latest version is being point by two tags named v and v0.16.3. In my case dh-make-golang has picked up the v tag, ending up with error because of the v prefix being removed.

This would not happen if I was able to choose the tag I want to checkout.
So this is my approach.

This should fix #31 and use a different approach than the one proposed in #34

Just let me know if you considered another approach.

Cheers

[creekorful]

PR updated with your recommendation.

[zhsj]

I'm not fully understand this PR and the relation with @nodens's issue of LXD.

I think there's no need for another command line arg, -git_revision is good here.

For bad tags, like the v in https://github.com/viant/afs, the best option I think is to ask upstream to remove this bad tag.

For LXD, which tags are not prefixed with v, I think we need to teach tarballFromHoster to use the origin string from git_revision to determine the tarball url, both for github and gitlab.

[zhsj]

I think there's no need for another command line arg, -git_revision is good here.

You can pass git tags to -git_revision.

[creekorful]

Hello @zhsj

I'm not fully understand this PR and the relation with @nodens's issue of LXD.

This PR was not really related with @nodens issue, more with my packaging error with AFS, my bad.

I think there's no need for another command line arg, -git_revision is good here.

For bad tags, like the v in https://github.com/viant/afs, the best option I think is to ask upstream to remove this bad tag.

I think it could be great not to 'depend' on upstream on this one, being able to force the packaging of a given tag could be a real improvement. What do you think?

For LXD, which tags are not prefixed with v, I think we need to teach tarballFromHoster to use the origin string from git_revision to determine the tarball url, both for github and gitlab.

This would allow packaging for sure, but we will end up with the wrong version number in the changelog for example. This is not really consistent.

You can pass git tags to -git_revision.

This is true. But the tag are then resolved to associated refspec, and then the real used tag will be retrieved from the refspec using git describe --abbrev=0 --tags --exclude */v*

In case two tags resolve to the same refspec, the one you'll provide to dh-make-golang may not be the one that will be used.

In my case the latest version was designed by two tags named v and v0.16.3. dh-make-golang has picked up the wrong named v tag, ending up with error because of the v prefix being removed.

[zhsj]

I think it could be great not to 'depend' on upstream on this one, being able to force the packaging of a given tag could be a real improvement. What do you think?

(This is only my personal thought). I think we should focus on real problems. And the latest tag from https://github.com/viant/afs is a good one.

[creekorful]

(This is only my personal thought). I think we should focus on real problems. And the latest tag from https://github.com/viant/afs is a good one.

IMHO it's a real problem. Sure the latest tag is a good one in my case, but this issue may (and certainly will) come back over and over.

The fact that the provided tag may not be the one packaged is a problem, it may confuse the maintainer, and in some case (like the once I have faced) break the packaging.

And we don't even have any way to bypass this behaviour. dh-make-golang will resolve the refspec and determinate the tag automatically, always.

Maybe it's not the right approach to fix the issue?
But I think it would be really great to enforce the tag to package.