Sorry for the late reply. 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? > > 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. 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. > 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
