Given that it has been two weeks, I don’t think we’re going to get a reply from debian-x :)
I’d suggest to just go ahead — I can’t see why the suggested approach wouldn’t work for debian-x, and even if they need something on top, it’d be easy to add that later. Guido, how do we proceed? Do you want to take care of this, or would you rely on an external patch for this feature? Thanks! On Mon, Jan 29, 2018 at 9:47 AM, Guido Günther <a...@sigxcpu.org> wrote: > Hi, > On Thu, Jan 25, 2018 at 09:32:01AM +0100, Michael Stapelberg wrote: > > On Thu, Jan 25, 2018 at 8:11 AM, Guido Günther <[1]a...@sigxcpu.org> > wrote: > > > > Hi Michael, > > On Wed, Jan 24, 2018 at 10:27:25PM +0100, Michael Stapelberg wrote: > > > Package: git-buildpackage > > > Version: 0.9.6 > > > Severity: wishlist > > > > > > When using a pure git workflow (no tarballs involved), as > documented > > in > > > > > file:///usr/share/doc/git-buildpackage/manual-html/gbp. > import.upstream-git.html, > > > it is common to configure the “upstream” git remote to be the > actual > > upstream, > > > whereas the “origin” git remote would be a repository on alioth. > > > > > > E.g., for the golang-text package, I would configure: > > > remote “origin” is git.debian.org:/git/pkg-go/ > packages/golang-text.git > > > remote “upstream” is [2]https://github.com/kr/text > > > > > > Now, when another team member of the pkg-go team uses gbp-clone > on the > > alioth > > > repository, they won’t get my “upstream” git remote configuration. > > > > > > This means publishing git repositories is lossy: what I have on my > > hard disk > > > does not reflect what other team members will get when they clone > the > > > repository. > > > > > > This makes updating packages way harder than it should be :) > > > > > > Could we add options to debian/gbp.conf to get an upstream git > remote > > configured > > > automatically when cloning please? > > > > For purely git based workflow this makes. For this to be nicely > > integrated we'd > > need to store the information somehwere in the packakge e.g. > > > > X-Upstream-VCS: > > > > in debian control so not each packaging team has to cook it's own > > solution. > > However it could be nicely protyped using gbp clone's postclone > hooks. > > Cheers, > > -- Guido > > > > Done, see > > [3]https://github.com/Debian/pkg-go-tools/blob/master/cmd/ > pgt-remote-add-upstream/upstream.go > > To install, use: > > % sudo apt install golang-go git > > % go get -u [4]github.com/Debian/pkg-go-tools/cmd/pgt-remote-add- > upstream > > Then, use the binary in ~/go/bin/pgt-remote-add-upstream as postclone > > hook. > > While this works for the time being, I’d like to see it in > > git-buildpackage proper, if only because hook configuration is > cumbersome > > to do in a packaging-group-specific way. > > I noticed that the xorg-team also has a similar > > script: [5]http://x.debian.net/reference/git-usage.html (search for > > “xsf-remote-add-upstream”). Theirs uses debian/watch. > > kibi, would xorg-team be happy with gbp looking at the > X-Vcs-Upstream-Git > > key/value pair in debian/control, or do you have any special > requirements? > > Yes, we should have this in gbp proper. It would be good to hear from > the xsf if this would fit for them as well (I notice that they use > debian/watch for that). > Cheers > -- Guido > -- Best regards, Michael
