I filed a wishlist bug for the remote configuration: https://bugs.debian.org/888313
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. I have a beginner question regarding the git upstream workflow we’re targeting: How exactly would I import a new upstream version? 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: % git remote add upstream https://github.com/kr/text % git fetch upstream % git branch -D upstream % git branch --track upstream upstream/master The upstream branch indeed contains one commit which is not yet reflected in the debian branch (“master”). 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”. However, I can’t find a git-buildpackage command to take care of this. How do you do it? Manually? On Tue, Jan 23, 2018 at 10:48 PM, Michael Stapelberg <[email protected]> wrote: > 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. > > The VCS composition is: > 889 git > 3 hg > 2 bzr > > I’ll need to look into how to use git-remote-{hg,bzr}. > > 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? > > On Thu, Nov 9, 2017 at 10:06 PM, Michael Stapelberg <[email protected] > > wrote: > >> Status update: I discovered (and documented) gbp’s postclone=origtargz >> option. Also, I prepared (and documented/referenced) two git hooks. >> >> I’m still not entirely certain about how to approach the “upstream >> branch contains upstream git history” change in the best way. >> Suggestions/tips welcome. >> >> On Thu, Nov 9, 2017 at 3:57 PM, Michael Stapelberg >> <[email protected]> wrote: >> > On Thu, Nov 9, 2017 at 6:44 AM, Martín Ferrari <[email protected]> >> wrote: >> >> On 09/11/17 04:24, Michael Stapelberg wrote: >> >> >> >>> At least for our transition period, we’ll have to use origtargz. >> >> >> >> Yes, but only for -2 and up releases. For -1, origtargz would do the >> >> same as gbp (AFAIK). >> > >> > Yes, for -1 releases, users supply the orig tarball :) >> > >> >> >> >>> I’m happy to pro-actively add compression algorithm/level options and >> >>> evaluate at a later time whether that worked. I think just testing >> >>> across different machines is a good start, but we should also pass the >> >>> test of time — perhaps we can easily simulate that by testing on >> >>> stable/oldstable. >> >> Not sure if we need to devote a lot of time to this, after all, the >> >> worst that can happen is a rejected upload because of checksum >> mismatches. >> > >> > Personally, I find rejected uploads super frustrating, especially >> > because of the large delay in between the action and the result (up to >> > half an hour). >> > >> > I’d really like to define a workflow which makes them a thing of the >> > past. For the time being, this is using origtargz. >> > >> > -- >> > Best regards, >> > Michael >> >> >> >> -- >> Best regards, >> Michael >> > > > > -- > Best regards, > Michael > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
