[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pkg-perl-cvs-commits post from legatvs@gmail.com requires approval



-=| pkg-perl-cvs-commits-owner@lists.alioth.debian.org, Thu, Apr 09, 2009 at 07:41:30AM +0000 |=-
> As list administrator, your authorization is requested for the
> following mailing list posting:
> 
>     List:    Pkg-perl-cvs-commits@lists.alioth.debian.org
>     From:    legatvs@gmail.com
>     Subject: [SCM] packaging of clive-utils branch, master, updated. 2.1.4-66-g9e36024
>     Reason:  Message body is too big: 68807 bytes with a limit of 40 KB

Sorry about this. The git post-recieve hook on alioth keeps reporting 
commits from the upstream branch that were (naturally) merged into the 
master branch.

Any hint how to avoid that is welcome. Here's the current procedure 
for upgrading the debian package:

# fetch new upstream tarball
$ uscan   # .bz2 gets recompressed to .gz by a hook
# refresh the local copy of upstream repository
$ git fetch upstream-repo
# merge the relevant upstream tag into the local upstream branch
$ git co upstream
$ git merge 2.1.10
# use git-import orig for pristine-tar integration and 
# debian/changelog bump
$ git co master
$ git-import-orig --pristine-tar ../clive_2.1.10.orig.tar.gz
# work on the package, tag, upload
...
# push changes to alioth
$ git push origin master upstream pristine-tar
$ git push origin --tags

With this procedure, the master branch log also shows all the upstream 
commits and these get included in the mail notification upon push :|

The only way I can think of to avoid this is to stop merging tags (and 
therefore commits) from upstream repository to the upstream branch 
(and consequently to the master branch). Instead, git-import-orig 
could simply roll the .orig.tar.gz into the upstream branch and create 
a single "new upstream release" commit that is then merged into 
master. That would break the natural relation between the upstream 
stream of commits and the debian packaging ones, therefore I don't 
like it. Sounds mostly "aestetical" problem, but if there is any other 
way to avoid that, I'd gladly keep things as they are now.

Ideas welcome.

-- 
dam            JabberID: dam@jabber.minus273.org

Attachment: signature.asc
Description: Digital signature


Reply to: