Re: Bug#888313: please allow git remote configuration (e.g. for upstream remote)

2018-02-13 Thread Guido Günther 
Hi,
Thanks for having a look.

On Tue, Feb 13, 2018 at 09:59:02AM +0100, Michael Stapelberg wrote:
> See the attached work-in-progress patch for how far I got at this point.
> Before I continue, here are two questions:
> 
> AFAICT, the control package doesn’t allow me to do case-insensitive
> lookups. Should we extend it to do that, or do we really want to insist on
> users capitalizing the directives correctly?

Policy says:

| Field names are not case-sensitive, but it is usual to capitalize the
| field names using mixed case as shown below. Field values are case-
| sensitive unless the description of the field says otherwise.

so we should capitalize them. We can likely do with a single control
file entry like:

X-Vcs-Upstream-Git:  -b 

which would match the existing Vcs-* syntax.

> Also, I’m wondering whether we should set up a branch automatically (e.g.
> “upstream” tracking “upstream/master”), not at all, or behind another
> option. This ties into our branch naming and import workflow discussion.
> Thoughts?

I would start out with naming the remote 'upstream'. I'm not sure
whether we need tracking branches. When I track remote git I usually
don't track upstream but rather only fetch from the remote. Different
people might have different expectations here so we likely need to come
up with an option to configure this.

Cheers,
 -- Guido

Re: Bug#888313: please allow git remote configuration (e.g. for upstream remote)

2018-02-13 Thread Michael Stapelberg 
See the attached work-in-progress patch for how far I got at this point.
Before I continue, here are two questions:

AFAICT, the control package doesn’t allow me to do case-insensitive
lookups. Should we extend it to do that, or do we really want to insist on
users capitalizing the directives correctly?

Also, I’m wondering whether we should set up a branch automatically (e.g.
“upstream” tracking “upstream/master”), not at all, or behind another
option. This ties into our branch naming and import workflow discussion.
Thoughts?

On Mon, Feb 12, 2018 at 12:13 PM, Michael Stapelberg 
wrote:

> When cloning a git repository containing Debian packaging (no matter
> whether you use git-clone or gbp-clone), you’ll end up with one or more
> branches all tracking the remote from which you cloned (e.g. alioth, or
> salsa).
>
> In debian-x, there is https://salsa.debian.org/xorg-team/debian/xsf-tools/
> blob/master/xsf-remote-add-upstream, which takes care of the problem.
>
> We’re discussing adding this feature to git-buildpackage, and were
> wondering whether the suggestion in this bug would be helpful for debian-x,
> too. If debian-x doesn’t use git-buildpackage, the question is moot of
> course (unless you intend to adopt it in the future) :).
>
> On Mon, Feb 12, 2018 at 12:02 PM, Julien Cristau 
> wrote:
>
>> On 02/11/2018 02:20 PM, Michael Stapelberg wrote:
>> > Given that it has been two weeks, I don’t think we’re going to get a
>> > reply from debian-x :)
>>
>> It's not clear to me what the question is.  I've also never used
>> git-buildpackage, so may be missing context.
>>
>> Cheers,
>> Julien
>>
>> >
>> > 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 > > > 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.impor
>> t.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/pac
>> kages/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/p
>> gt-remote-add-upstream/upstream.go
>> > > -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
>> > 
>>

Re: Bug#888313: please allow git remote configuration (e.g. for upstream remote)

2018-02-12 Thread Michael Stapelberg 
When cloning a git repository containing Debian packaging (no matter
whether you use git-clone or gbp-clone), you’ll end up with one or more
branches all tracking the remote from which you cloned (e.g. alioth, or
salsa).

In debian-x, there is
https://salsa.debian.org/xorg-team/debian/xsf-tools/blob/master/xsf-remote-add-upstream,
which takes care of the problem.

We’re discussing adding this feature to git-buildpackage, and were
wondering whether the suggestion in this bug would be helpful for debian-x,
too. If debian-x doesn’t use git-buildpackage, the question is moot of
course (unless you intend to adopt it in the future) :).

On Mon, Feb 12, 2018 at 12:02 PM, Julien Cristau 
wrote:

> On 02/11/2018 02:20 PM, Michael Stapelberg wrote:
> > Given that it has been two weeks, I don’t think we’re going to get a
> > reply from debian-x :)
>
> It's not clear to me what the question is.  I've also never used
> git-buildpackage, so may be missing context.
>
> Cheers,
> Julien
>
> >
> > 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  > > 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
> >  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

Re: Bug#888313: please allow git remote configuration (e.g. for upstream remote)

2018-02-12 Thread Julien Cristau 
On 02/11/2018 02:20 PM, Michael Stapelberg wrote:
> Given that it has been two weeks, I don’t think we’re going to get a
> reply from debian-x :)

It's not clear to me what the question is.  I've also never used
git-buildpackage, so may be missing context.

Cheers,
Julien

> 
> 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  > 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

Re: Bug#888313: please allow git remote configuration (e.g. for upstream remote)

2018-02-11 Thread Guido Günther 
On Sun, Feb 11, 2018 at 02:20:55PM +0100, Michael Stapelberg wrote:
> Given that it has been two weeks, I don’t think we’re going to get a reply
> from debian-x :)

Agreed.

> 
> 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!

A patch (including tests and docs) would be welcome since my time to
work in gbp is currently quiet limited and I have some other bugs I
need to look at first.

Cheers,
 -- Guido

Re: Bug#888313: please allow git remote configuration (e.g. for upstream remote)

2018-02-11 Thread Michael Stapelberg 
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  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

Re: Bug#888313: please allow git remote configuration (e.g. for upstream remote)

2018-01-25 Thread Michael Stapelberg 
Sorry about that. Maybe it would be good to update the header of
http://x.debian.net/reference/git-usage.html with up-to-date contact info,
in that case :)

On Thu, Jan 25, 2018 at 9:38 AM, Cyril Brulebois  wrote:

> Hi,
>
> Quoting in full for debian-x@:
>
> Michael Stapelberg  (2018-01-25):
> > On Thu, Jan 25, 2018 at 8:11 AM, Guido Günther  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 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
> > 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 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:
> > 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?
>
> It's been a few years since I left the X maintenance team, so you'd have
> to ask debian-x@ members/actual maintainers.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>



-- 
Best regards,
Michael

Re: Bug#888313: please allow git remote configuration (e.g. for upstream remote)

2018-01-25 Thread Cyril Brulebois 
Hi,

Quoting in full for debian-x@:

Michael Stapelberg  (2018-01-25):
> On Thu, Jan 25, 2018 at 8:11 AM, Guido Günther  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 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
> 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 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:
> 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?

It's been a few years since I left the X maintenance team, so you'd have
to ask debian-x@ members/actual maintainers.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature