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.
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.
>> 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
I tried to work around this error by setting upstream-branch=debian/sid
(that is, upstream-branch = debian-branch). It is the branch that
contains the commit the upstream version tag refers to, after all. In
this case we get the behavior I described:
$ 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/debian/sid']
gbp:info: Dry-run: Pushing 1.5.0 to origin
gbp:debug: ['git', 'push', 'origin', 'tag', '1.5.0', '--dry-run']
gbp:info: Dry-run: Pushing 2ac8d1947dab3f545fe42d910681dd0253cb79a3 to
origin:refs/heads/debian/sid
gbp:debug: ['git', 'push', 'origin', '--dry-run',
'2ac8d1947dab3f545fe42d910681dd0253cb79a3:refs/heads/debian/sid']
gbp:error: Error running git push: To salsa.debian.org:paride-guest/spm.git
! [rejected] 2ac8d1947dab3f545fe42d910681dd0253cb79a3 ->
debian/sid (non-fast-forward)
error: failed to push some refs to
'g...@salsa.debian.org:paride-guest/spm.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
gbp:error: Failed to push some refs.
https://salsa.debian.org/paride-guest/spm is the repo I'm working with.
> I think I can see where the problem you describe comes from but it's
> unrelated whether you have an upstream branch or not (I'm maintaining
> several packages directly out of git). It's a rather long standing bug
> in "gbp push" that it doesn't cope well with pushing older releases I
> think it did not make it to the BTS yet so this report is the perfect
> opportunity!
They may very well be related, but I think that in my case the point is
the absence of the upstream branch.
Thanks again,
Paride
