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? There certainly is
a
branch where upstream development happens on.
> Should we conclude that I'm wrong and that there are good reasons to
> maintain an upstream branch, then the central point of this report will
> cease to exist.
The main reason is cherry-picking from this branch is simple with
gbp-pq, etc.
> >> and DEP14 somehow implies that an upstream branch may not exist by not
> >> mentioning it at all in the "Importing upstream releases from Git tags"
> >> section.
>
> And, should we conclude that an upstream branch has to be maintained, I
> think DEP14 should be more explicit on this point.
>
> >> Now, coming to the point of this report. When ‘gbp push’ is called, it
> >> will look for the branch where commit tagged with the release version
> >> lies, and it will try to push this refspec to the corresponding remote
> >> branch. When working without an upstream branch, the tag will refer to a
> >> commit in the debian branch, and this commit will be behind the branch tip.
> >
> > "in the debian branch" is not defined in git. Upstream as well as Debian
> > tags are always reachable from the Debian branch. Upstream-tags are
> > reachable from the Upstream branch as well whereas Debian tags are not..
> >
> > By released version do you refer to the Debian or upstream version?
>
> I forgot to mention something here -- sorry. If there is no upstream
> branch, gbp-push fails as you may expect (debian-branch=debian/sid):
>
> $ gbp push --verbose --dry-run
> gbp:debug: ['git', 'rev-parse', '--show-cdup']
> gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> gbp:debug: ['git', 'rev-parse', '--git-dir']
> gbp:debug: ['git', 'symbolic-ref', 'HEAD']
> gbp:debug: ['git', 'show-ref', 'refs/heads/debian/sid']
> gbp:debug: ['git', 'config', 'branch.debian/sid.remote']
> gbp:debug: ['git', 'tag', '-l', 'debian/1.5.0-1']
> gbp:debug: ['git', 'tag', '-l', '1.5.0']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', '1.5.0^{commit}']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify',
> '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.
Cheers,
-- Guido
