<div dir="ltr">I filed a wishlist bug for the remote configuration: <a href="https://bugs.debian.org/888313">https://bugs.debian.org/888313</a><div><br></div><div>My tooling is now able to work with almost all repositories — there are about 20 which still require some fixes, I’ll send out emails where I can’t do the fix myself.</div><div><br></div><div>I have a beginner question regarding the git upstream workflow we’re targeting:</div><div>How exactly would I import a new upstream version?</div><div><br></div><div>I looked at the golang-text repository (gbp clone vcsgit:golang-text), removed the existing upstream branch, configured the correct remote and tracked its master branch:</div><div><div>% git remote add upstream <a href="https://github.com/kr/text">https://github.com/kr/text</a></div><div>% git fetch upstream</div><div>% git branch -D upstream<br></div><div>% git branch --track upstream upstream/master<br></div><div><br></div></div><div>The upstream branch indeed contains one commit which is not yet reflected in the debian branch (“master”).</div><div><br></div><div>To import it, AIUI, I should tag the latest upstream branch commit (7cafcd837844e784b526369c9bce262804aebc60) with tag upstream/0.0_git20160503.7cafcd8, then merge the upstream branch into the master branch with the merge strategy “theirs”.</div><div><br></div><div>However, I can’t find a git-buildpackage command to take care of this. How do you do it? Manually?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 23, 2018 at 10:48 PM, Michael Stapelberg <span dir="ltr"><<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Status update: I now have tooling to perform the “delete existing upstream branch, create a tracking upstream branch in correct version from Go import path” step. The tooling still fails on about 60 of 901 repositories. I’ll take a look at the failures and give another status update.<div><br></div><div>The VCS composition is:</div><div>889 git</div><div>3 hg</div><div>2 bzr</div><div><br></div><div>I’ll need to look into how to use git-remote-{hg,bzr}.</div><div><br></div><div>Also, I’m wondering how we can accomplish automated git remote configuration, i.e. how do people obtain an upstream branch which tracks the correct upstream remote branch? AFAICT, git-buildpackage has no solution for this (yet?). Does anyone know by chance?</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Nov 9, 2017 at 10:06 PM, Michael Stapelberg <span dir="ltr"><<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Status update: I discovered (and documented) gbp’s postclone=origtargz<br>
option. Also, I prepared (and documented/referenced) two git hooks.<br>
<br>
I’m still not entirely certain about how to approach the “upstream<br>
branch contains upstream git history” change in the best way.<br>
Suggestions/tips welcome.<br>
<div class="m_8309093334920026439HOEnZb"><div class="m_8309093334920026439h5"><br>
On Thu, Nov 9, 2017 at 3:57 PM, Michael Stapelberg<br>
<<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>> wrote:<br>
> On Thu, Nov 9, 2017 at 6:44 AM, Martín Ferrari <<a href="mailto:tincho@tincho.org" target="_blank">tincho@tincho.org</a>> wrote:<br>
>> On 09/11/17 04:24, Michael Stapelberg wrote:<br>
>><br>
>>> At least for our transition period, we’ll have to use origtargz.<br>
>><br>
>> Yes, but only for -2 and up releases. For -1, origtargz would do the<br>
>> same as gbp (AFAIK).<br>
><br>
> Yes, for -1 releases, users supply the orig tarball :)<br>
><br>
>><br>
>>> I’m happy to pro-actively add compression algorithm/level options and<br>
>>> evaluate at a later time whether that worked. I think just testing<br>
>>> across different machines is a good start, but we should also pass the<br>
>>> test of time — perhaps we can easily simulate that by testing on<br>
>>> stable/oldstable.<br>
>> Not sure if we need to devote a lot of time to this, after all, the<br>
>> worst that can happen is a rejected upload because of checksum mismatches.<br>
><br>
> Personally, I find rejected uploads super frustrating, especially<br>
> because of the large delay in between the action and the result (up to<br>
> half an hour).<br>
><br>
> I’d really like to define a workflow which makes them a thing of the<br>
> past. For the time being, this is using origtargz.<br>
><br>
> --<br>
> Best regards,<br>
> Michael<br>
<br>
<br>
<br>
</div></div><span class="m_8309093334920026439HOEnZb"><font color="#888888">--<br>
Best regards,<br>
Michael<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_8309093334920026439gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div>