Hi,
On Mon, May 21, 2018 at 11:22:31AM +0200, Paride Legovini wrote:
> Package: git-buildpackage
> Version: 0.9.8
> Severity: normal
>
> Dear gbp maintainers/devs,
>
> 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.
> 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.
>
> 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?
> As gbp-push pushes up the the tag, the push command will fail
> ("non-fast-forward" error).
As reportbug suggests: please include the full output run with "-v".
Even better provide a repo and steps to reproduce. Can you provide
either of these please?
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!
> One way to work around this would be to check if the commit has already
> been pushed. This should be doable with:
>
> git branch -r --contains <commit>
Yeah, that's what I had i mind but we might end up having to run "gbp
clone" first (or at least suggesting that to the user). But I'd like to
understand the full problem first.
Cheers,
-- Guido
> which should probably be run after a fetch. People with a more complete
> picture of gbp in mind will probably have better ideas.
>
> Cheers,
>
> Paride
