On Sun, Jul 30, 2017 at 6:10 AM, Osamu Aoki <os...@debian.org> wrote:
> (I switched my ISP. No more osamua...@e01.itscom.net Thanks for the
> 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 <osamua...@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"
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
> 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
Sounds great! I can’t make it to this DebConf, but I wish you safe travels
and a great conference!
Thanks in advance,
Pkg-go-maintainers mailing list