[pkg-go] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

Hi Osamu,

Sorry for the late reply, and thanks for looking into this! Replies
inline:

Osamu Aoki <osamuaoki at e01.itscom.net> writes:
> How should we explicitly specify such variables, I guess it should be
> through "opts=..." such as:
>
>  opts="mode=git, pretty=0.0~git%cd.%h, date=%Y%m%d%H%M"

Sounds good.

>
> But this "git log" needs to have local clone of git repository.
>
> I wonder if I can do without cloning first.

After reading the git protocol and searching on the web for a little
bit, my conclusion is that no, you cannot use “git log” without having a
clone of the repository.

Given that we are talking about repositories which do not use tags, we
could specify --depth=1 when cloning to get a shallow clone, i.e. only
the latest commit. That saves bandwidth and disk space, but has the
downside that we cannot do any additional validation, i.e. we can’t
detect if upstream ever starts using tags — unfortunately, that is a
plausible scenario, so I would suggest doing a full clone.

For GitHub, we can apply an optimization: the GitHub HTTP API exposes
repository details, such as:

1. The default_branch of the repo, in
   https://developer.github.com/v3/repos/#get

2. The latest commit of the branch, in
   https://developer.github.com/v3/repos/branches/#get-branch

For interactive use by individual developers, we could send these HTTP
requests unauthenticated. For a setup which does many uscan calls, we’d
need to create a GitHub account to get the higher rate limit. See
https://godoc.org/github.com/google/go-github/github#hdr-Rate_Limiting
for details.

> Adding support to the number of commits is complicated.  Let's be happy
> to use hash to be unique commit.  I do not think we upload more than 2
> Debian upstream tarball in a minute.

In a day, not in a minute. But regardless, you are probably right. I
asked in the pkg-go IRC channel to see whether people are okay with
removing that part from the version number, so barring any objections,
we can probably get that done within the next few days.

> As for "git describe" like nearest tag feature, it's a interesting
> thought but it may make things more complicate.  So unless someone
> strongly request with patch, I would like to skip it.

Agreed — if we get rid of the number of commits, we shouldn’t need git
describe, not even in dh-make-golang.

It seems like you have a good handle on implementing this in uscan. Do
you need any additional details? Do you prefer an external patch from
us over implementing this yourself? I’d be happy to give you feedback on
a proposed patch or git commit.

Thank you very much!

-- 
Best regards,
Michael