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

[Osamu Aoki]

Hi,

(I switched my ISP.  No more osamuaoki at e01.itscom.net  Thanks for the
reminder)

On Sat, Jul 29, 2017 at 06:44:43PM +0200, Michael Stapelberg wrote:
> Hi Osamu,
> 
> Sorry for the late reply, and thanks for looking into this! Replies
> inline:

It's good time to make feature enhancements now.
 
> 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.

I had to read the whole thread to recall what I was thinking ... OK ;-)

> > 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.

OK with FULL clone.  (I need to rethink details though... I totally lost
my memory on this topic)

The thing to consider is what git local repository looks like and how
you clone such remote tree. "upstream" branch used by git-buildpackage
is not really the upstream git repository but its series of commits from
the released upstream tarballs.  Maybe clone it into "upstream-git"
branch...

> 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.

(This optimization is a bit more work than I can do immediately.)

> > 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.

Why in a day?

%cd is committer date and this format respects --date= option.
--date option I suggested was %Y%m%d%H%M" which specified down to minutes;-)
If you insist, I can add seconds ;-)

> > 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.

OK.  I guess this will be a nice project during My Debconf17 travel for
me.

Osamu