Hi, (I switched my ISP. No more [email protected] 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 <[email protected]> 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 _______________________________________________ devscripts-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
