<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 30, 2017 at 6:10 AM, Osamu Aoki <span dir="ltr"><<a href="mailto:osamu@debian.org" target="_blank">osamu@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
(I switched my ISP.  No more <a href="mailto:osamuaoki@e01.itscom.net">osamuaoki@e01.itscom.net</a>  Thanks for the<br>
reminder)<br>
<span class=""><br>
On Sat, Jul 29, 2017 at 06:44:43PM +0200, Michael Stapelberg wrote:<br>
> Hi Osamu,<br>
><br>
> Sorry for the late reply, and thanks for looking into this! Replies<br>
> inline:<br>
<br>
</span>It's good time to make feature enhancements now.<br>
<span class=""><br>
> Osamu Aoki <<a href="mailto:osamuaoki@e01.itscom.net">osamuaoki@e01.itscom.net</a>> writes:<br>
> > How should we explicitly specify such variables, I guess it should be<br>
> > through "opts=..." such as:<br>
> ><br>
> >  opts="mode=git, pretty=0.0~git%cd.%h, date=%Y%m%d%H%M"<br>
><br>
> Sounds good.<br>
<br>
</span>I had to read the whole thread to recall what I was thinking ... OK ;-)<br>
<span class=""><br>
> > But this "git log" needs to have local clone of git repository.<br>
> ><br>
> > I wonder if I can do without cloning first.<br>
><br>
> After reading the git protocol and searching on the web for a little<br>
> bit, my conclusion is that no, you cannot use “git log” without having a<br>
> clone of the repository.<br>
><br>
> Given that we are talking about repositories which do not use tags, we<br>
> could specify --depth=1 when cloning to get a shallow clone, i.e. only<br>
> the latest commit. That saves bandwidth and disk space, but has the<br>
> downside that we cannot do any additional validation, i.e. we can’t<br>
> detect if upstream ever starts using tags — unfortunately, that is a<br>
> plausible scenario, so I would suggest doing a full clone.<br>
<br>
</span>OK with FULL clone.  (I need to rethink details though... I totally lost<br>
my memory on this topic)<br>
<br>
The thing to consider is what git local repository looks like and how<br>
you clone such remote tree. "upstream" branch used by git-buildpackage<br>
is not really the upstream git repository but its series of commits from<br>
the released upstream tarballs.  Maybe clone it into "upstream-git"<br>
branch...<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> For GitHub, we can apply an optimization: the GitHub HTTP API exposes<br>
> repository details, such as:<br>
><br>
> 1. The default_branch of the repo, in<br>
>    <a href="https://developer.github.com/v3/repos/#get" rel="noreferrer" target="_blank">https://developer.github.com/<wbr>v3/repos/#get</a><br>
><br>
> 2. The latest commit of the branch, in<br>
>    <a href="https://developer.github.com/v3/repos/branches/#get-branch" rel="noreferrer" target="_blank">https://developer.github.com/<wbr>v3/repos/branches/#get-branch</a><br>
><br>
> For interactive use by individual developers, we could send these HTTP<br>
> requests unauthenticated. For a setup which does many uscan calls, we’d<br>
> need to create a GitHub account to get the higher rate limit. See<br>
> <a href="https://godoc.org/github.com/google/go-github/github#hdr-Rate_Limiting" rel="noreferrer" target="_blank">https://godoc.org/github.com/<wbr>google/go-github/github#hdr-<wbr>Rate_Limiting</a><br>
> for details.<br>
<br>
</span>(This optimization is a bit more work than I can do immediately.)<br></blockquote><div><br></div><div>That’s fair. I’m happy to help with a patch for uscan to apply this optimization, once the foundation for it is done.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > Adding support to the number of commits is complicated.  Let's be happy<br>
> > to use hash to be unique commit.  I do not think we upload more than 2<br>
> > Debian upstream tarball in a minute.<br>
><br>
> In a day, not in a minute. But regardless, you are probably right. I<br>
> asked in the pkg-go IRC channel to see whether people are okay with<br>
> removing that part from the version number, so barring any objections,<br>
> we can probably get that done within the next few days.<br>
<br>
</span>Why in a day?<br>
<br>
%cd is committer date and this format respects --date= option.<br>
--date option I suggested was %Y%m%d%H%M" which specified down to minutes;-)<br>
If you insist, I can add seconds ;-)<br></blockquote><div><br></div><div>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 :).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > As for "git describe" like nearest tag feature, it's a interesting<br>
> > thought but it may make things more complicate.  So unless someone<br>
> > strongly request with patch, I would like to skip it.<br>
><br>
> Agreed — if we get rid of the number of commits, we shouldn’t need git<br>
> describe, not even in dh-make-golang.<br>
><br>
> It seems like you have a good handle on implementing this in uscan. Do<br>
> you need any additional details? Do you prefer an external patch from<br>
> us over implementing this yourself? I’d be happy to give you feedback on<br>
> a proposed patch or git commit.<br>
<br>
</span>OK.  I guess this will be a nice project during My Debconf17 travel for<br>
me.</blockquote><div><br></div><div>Sounds great! I can’t make it to this DebConf, but I wish you safe travels and a great conference!</div><div><br></div><div>Thanks in advance,</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div></div>