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

[Michael Stapelberg]

On Sun, Jul 30, 2017 at 6:10 AM, Osamu Aoki <osamu at debian.org> wrote:

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

Wouldn’t it be cleaner to not modify the local repository at all, i.e.
clone in a separate, temporary directory? Aside from a new orig tarball,
uscan doesn’t leave files behind usually, does it?


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

That’s fair. I’m happy to help with a patch for uscan to apply this
optimization, once the foundation for it is done.


>
> > > 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 ;-)
>

Ah, now I see where you’re coming from. We’re currently using day
granularity, and don’t want to change that, so we’re restricted to 1 upload
per day :).


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


Sounds great! I can’t make it to this DebConf, but I wish you safe travels
and a great conference!

Thanks in advance,

-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20170730/c3736fc7/attachment.html>