On 22/05/2018 07.39, Guido Günther wrote: > Hi, > On Mon, May 21, 2018 at 02:39:00PM +0200, Paride Legovini wrote: >> On 21/05/2018 13.04, Guido Günther wrote: >>> Hi, >> >> Hi Guido, thanks for your reply. >> >>> On Mon, May 21, 2018 at 11:22:31AM +0200, Paride Legovini wrote: >>>> >>>> When working with git remotes and tags (instead of importing upstream >>>> tarballs) an upstream branch is not normally not needed or wanted. This >>>> kind of workflow is not uncommon, in fact is is suggested by the gbp >>>> documentation: >>>> >>>> /usr/share/doc/git-buildpackage/manual-html/gbp.import.upstream-git.html >>> >>> I think the documentation above does not suggest that there is no >>> upstream branch, rather that you don't need gbp import-orig to maintain >>> it. At least that's the intention. If that's not the case please let >>> me know where you read that not having a branch with pristine upstream >>> source is a good idea. We should fix that then. >> >> I was hoping to get a comment on this. :) >> >> The idea that gbp.import.upstream-git.html somehow suggests that an >> upstream branch is not necessary comes from the following facts: >> >> (1) In the proposed workflow, an upstream branch is not mentioned. The >> document is almost a step-by-step guide, for example it shows how to >> fetch and merge a new upstream release, but no hint is given on how to >> maintain an upstream branch. >> >> (2) By following that workflow, the master branch is almost what an >> upstream branch should be. Actually, in the beginning I thought that I >> had to consider the upstream branch to be "master". But this branch is >> never updated: the new upstream versions are merged directly in the >> Debian branch. >> >> (3) When releases are tagged upstream, I don't see the advantage of >> maintaining an upstream branch. Tags can be checkedout and already >> represent the pristine upstream source. This seems to be a sound idea, >> and in fact by default we have upstream-tree=TAG. > > Well by "maintaining" you mean having this ref in your repo?
Yes, but I also mean keeping it up to date, merging the latest upstream release tag when a new release is packaged. Basically, by "maintaining" I mean reproducing the upstream branch import-orig would create (with a different git history, of course) and publishing (pushing) it. But I see there is no need for doing so in a pure git workflow, and this is completely reasonable. >> 'refs/heads/upstream'] >> gbp:error: revision 'refs/heads/upstream' not found > > O.k., this can be fixed by not pushing anything if the > corresponding branch or tag name is empty. E.g. > > gbp push --upstream-branch='' > > would omit that branch. Same for debian-branch, debian-tag and > ustream-tag when set on the command line or in gbp.conf. I'll push a > patch for this once I'm near my smart card again. Well, thanks a lot Guido, not only for implementing this, but for the general discussion too. Paride
