Hi Michael,
On Mon, Dec 19, 2016 at 08:41:38AM +0100, Michael Stapelberg wrote:
> On Fri, Nov 25, 2016 at 2:06 PM, Guido Günther <a...@sigxcpu.org> wrote:
>
> > Hi Michael,
> > On Thu, Nov 24, 2016 at 12:34:56PM +0100, Michael Stapelberg wrote:
> > > Hi Axel and Guido,
> > >
> > > Axel Beckert <a...@debian.org> writes:
> > > > But it would be nice to do the pushing of branches and tags in one
> > > > short DWIM command instead of two short commands or one long command
> > > > (git push + git push --tags or listing all refs manually), like "dpt
> > > > push" does. So I extended "dpt push" to parse gbp.conf files, so that
> > > > I can use it outside the Debian Perl Group, too, e.g. for the Debian
> > > > Zsh Maintainers.
> > >
> > > I do agree, pushing in one command is much more user-friendly than not
> > > providing any help when pushing. I used to forget pushing the
> > > pristine-tar/upstream branches and/or tags _ALL THE TIME_.
> > >
> > > It was such a big problem for me that I wrote a custom wrapper for gbp
> > > clone, which would set up the repository in such a way that I couldn’t
> > > forget anymore:
> > >
> > > # This tells git to push all branches at once,
> > > # i.e. if you changed upstream and debian (after
> > git-import-orig),
> > > # both upstream and debian will be pushed when running “git
> > push”.
> > > git config push.default matching
> > >
> > > # This tells git to push tags automatically,
> > > # so you don’t have to use “git push && git push --tags”.
> > > git config --add remote.origin.push "+refs/heads/*:refs/heads/*"
> > > git config --add remote.origin.push "+refs/tags/*:refs/tags/*"
> > >
> > > Needless to say, the above could easily be added to gbp clone, so that
> > > at least newly cloned repositories would be set up accordingly.
> > >
> > > What do you think of the solution above, i.e. configuring git so that
> > > “git push” is all that’s necessary, instead of introducing a new “gbp
> > > push” command? Would a corresponding patch be accepted into
> > > git-buildpackage?
> >
> > Thanks for looking into this. I think we need a "gbp push" after all
> > since matching strategy might be too broad: you might not want to push
> > changes for all releases and you might want to upload what you just
> > built in one go.
> >
>
> How do you envision the user interface to look like for this tool? I.e.,
> what sort of command invocations should users use in order to upload
> changes?
>
>
> >
> > [gbp-posttag-push][0] does parts of the job already. It mostly needs
> > some cleanup and robustness to be turned into a gbp-push.
> >
>
> I’m happy to work on this, if you provide some more details as to what
> exactly “some cleanups” entails :).
Axel describes his use of dpt-push as:
…
* Install the resulted packages and test them
* Run "git-buildpackage --git-tag-only" to set the tags
* Run dput on the changes file
* If the upload succeeds, then run "dpt push", i.e. push all relevant
branches and tags.
And I'm ussing gbp buildpackage --git-tag-only like:
* gbp buildpackage (build, run autopkg tests, run lintian)
* Install the resulted packages and test them
* Run "git-buildpackage --git-tag-only" to
* Run dput on the changes file
* Push tags
So I'd say "gbp push" would
0.) Check if we're in a git repo and the repo is clean
1.) Check if topmost changelog is != UNRELEASED
2.) Check if there's a tag referring to the topmost changelog entry
3.) Check if there's an upstream tag available
4.) Check if there's a corresponding changes file available (and no .upload)
5.) Check if we can push debian branch, debian tag, upstream tag, upstream
branch, pristine-tar branch
6.) dput the changes
7.) Push debian branch, debian tag, upstream tag, upstream
branch, pristine-tar branch
gbp-posttag-push does 6. and 7. but it can skip some of the checks since
it can assume that it's called from within a git repo (since it's a hook
and that some of the tags are already there, since it's a posttag
hook). We'd need to add these when turning it into a standalone command.
We also need to add a manpage.
We should probably also add sloppy mode that just pushes whatever is on
the debian-branch to the remote side but that can be done in a later
version.
We also need to make the remote configurable but this can also be added
n a later version.
Hope I didn't miss something. Thanks for having look!
-- Guido
