On Sat, Dec 31, 2016 at 3:18 PM, Eric Blake <[email protected]> wrote: > I'm considering the use of do-release-commit-and-tag for releasing m4 > 1.4.18, but I tested it while in the middle of a git rebase, and got: > > $ ./build-aux/do-release-commit-and-tag 1.4.18 stable > ./build-aux/do-release-commit-and-tag: line 146: test: too many arguments > do-release-commit-and-tag: not on branch (no branch, rebasing branch-1.4) > > > The following is a rough patch that would avoid the improper use of > test, but it still leaves a wonky error message. I'm not sure if a > better fix would be a change to the computation of the default value of > $branch earlier in the file. I guess that means I'm not even sure of > the best way to use the script. > > Suggestions? > > > diff --git i/build-aux/do-release-commit-and-tag > w/build-aux/do-release-commit-and-tag > index b4f3251..02e5f52 100755 > --- i/build-aux/do-release-commit-and-tag > +++ w/build-aux/do-release-commit-and-tag > @@ -3,7 +3,7 @@ > # controlled .prev-version file, automate the procedure by which we record > # the date, release-type and version string in the NEWS file. That commit > # will serve to identify the release, so apply a signed tag to it as well. > -VERSION=2016-01-12.23 # UTC > +VERSION=2016-12-31.14 # UTC > > # Note: this is a bash script (could be zsh or dash) > > @@ -143,7 +143,7 @@ esac > > # Ensure the current branch name is correct: > curr_br=$(git rev-parse --symbolic-full-name HEAD) > -test "$curr_br" = refs/heads/$branch || die not on branch $branch > +test "$curr_br" = "refs/heads/$branch" || die not on branch $branch > > # Extract package name from Makefile. > Makefile=$builddir/Makefile > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >
Hi Eric, That patch looks fine. I use that script only via the instructions in a typical README-release file, e.g., I ran commands like this for yesterday's sed-4.3 release: make release-commit RELEASE='4.3 stable' make release RELEASE='4.3 stable' It sounds like you're on the right track, adding gitlog-to-changelog support.
