On Sun, Jul 30, 2017 at 6:10 AM, Osamu Aoki <os...@debian.org> wrote:
> Hi, > > (I switched my ISP. No more osamua...@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 <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" > 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
_______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
