On 20/08/17 18:46, Michael Stapelberg wrote:

> Side note, not meant to persuade anyone one way or the other: I just
> realized why I never saw any appeal in that argument: I find git
> packaging (or git in general?) too brittle and confusing to keep what
> I consider are multiple projects in the same repository.

Uhm.. I don't really have that feeling. Could you elaborate more?

> When I need to find out something about upstream repositories, I
> usually use the GitHub web interface, or my local gopath. I never use
> the git packaging repos, regardless of whether they have history or
> not.

Heh, I hate the github web interface, can't compare to gitk, git log, etc :)

Also, I don't even have a go path. To this day I get confused every time
I try to build things by hand!

>         git config --add remote.origin.push "+refs/heads/*:refs/heads/*"
>         git config --add remote.origin.push "+refs/tags/*:refs/tags/*"

The problem with this is that you push all tags and branches, even if
they are coming from upstream (I know, not relevant for you). I try to
keep the alioth repo free from that.

> But note that gbp recently gained “gbp push”:
> https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=cbacdfb40ca35633da06e9e05497ac0fb56cc4f9
> It’s included in 0.9.0~exp2, but I haven’t tried it out yet.
> Hopefully, it makes both our extra setup steps unnecessary :).

Oh, cool, I should try it!

> Given that you _also_ maintain history in git, using gbp dch seems
> like significantly cutting down the number of commands. Is there any
> rationale behind your decision to not use gbp dch, or are you just
> used to this way? :)

Mostly historical reasons and muscle memory :)

Martín Ferrari (Tincho)

Pkg-go-maintainers mailing list

Reply via email to