Hi Michael, On Thu, Mar 23, 2017 at 10:13:27AM +0100, Michael Stapelberg wrote: > Sorry for the late reply.
Same here. > > On Fri, Dec 23, 2016 at 7:23 PM, Guido Günther <a...@sigxcpu.org> wrote: > > > 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) > > > > See point 6. > > > > 5.) Check if we can push debian branch, debian tag, upstream tag, upstream > > branch, pristine-tar branch > > > > Technically speaking, how would this check work specifically? I've done this already in the meantime. See gbp-posttag-push: https://github.com/agx/git-buildpackage/blob/master/examples/gbp-posttag-push#L235 and https://github.com/agx/git-buildpackage/blob/master/examples/gbp-posttag-push#L252 > > 6.) dput the changes > > > > I frequently use --git-export-dir, i.e. the .changes files end up in some > directory which has no relation whatsoever to the git directory in which > I’m working. > > How would gbp push find the .changes files? Storing a symlink (or similar) > in the working directory feels unclean. Prescribing a certain path for the > changes files feels unclean. Adding a flag to gbp push seems like it would > undermine the simplification we’re trying to achieve. I would look for it in ../ or export-dir. > It seems cleaner to me to not look at/touch any .changes files. Especially > since users can easily achieve the same effect by using dput && gbp > push. Simplifying the build -> push -> dput cycle and making it more robust is some thing I'd like to see with "gbp push" (and what I'm currently using in gbp-posttag-push). That said if "gbp push" starts with "only" the git pushing that's fine with me as long as we can share the code between "gbp push" and "gbp-posttag-push". We can then move over parts as we go. > > 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 > > > > > > -- > Best regards, > Michael Cheers, -- Guido
