[Pkg-puppet-devel] Tags and upstream

[Stig Sandbeck Mathisen]

Micah Anderson <micah at riseup.net> writes:

> Last night, when pushing the 2.7.11-1 tag, I accidentally pushed all
> upstream's tags,

I've done that myself, on another package, with about as many releases.

*bing* you have mail, *bing* you have mail, *bing*.... :D

> some of which were refused. I went through and removed them all, but I
> first had to disable the update hook because it was denying me from
> doing interesting tags. I'm not even sure where that hook came from,
> does anyone know? It seems to have been created in 2007, based on the
> filesystem.

If it was the "update" hook (now called "update.disabled"), it just
prevents the repo from accepting tags with no annotation (and GPG
signature).

This is visible at
http://anonscm.debian.org/gitweb/?p=pkg-puppet/puppet.git, where you see
some tags in the list with no description. The hook would prevent these
From being pushed to the repo.

Debian release tags (like
http://anonscm.debian.org/gitweb/?p=pkg-puppet/puppet.git;a=tag;h=2e53d22ac166fe39ff92caedfaff3e5451e9500a
) should be annotated and signed.

You can safely remove the debian/2.7.11-1 tag, and replace it with a
signed one, if you like.

# replace last tag with a signed one.  Normal use is without
# "--git-retag"
git buildpackage --git-tag-only --git-retag --git-sign-tags

git push origin :debian/2.7.11-1 # delete old remote tag
git push origin debian/2.7.11-1 # push new, signed tag

(assuming your remote to "git.debian.org" is called "origin")

We would need to replace our local tags after that. "git tag -d
debian/2.7.11-1" and "git remote update" would get the new one.

> I also had some problems merging the upstream's release into master,
> there were quite a few merge conflicts, which I would not expect as
> going from pristine upstream X to pristine upstream Y should not
> result in conflicts, so I'm a little puzzled about the state of that
> branch. In the end I had to do 'git merge upstream/<newversion> -X
> theirs' to merge in the new upstream. Perhaps its been done in a
> different way recently?

It looks like the "2.7.11" tarball was imported on top of the "2.6.3rc1"
upstream release instead of "2.7.10".

It makes the diff rather large, and the git history interesting, but it
should not have any effect on the generated debian source or binary
packages.

(The commmit "15b6a3e8c54c0199926cde04e8a6c0da3acde3bb" has
"1f6c832d659a0829e05427fb4e266980741a3481" as parent commit. It should
have had "c17b3ba16e7013f06416f10b8752ef783f048717" as parent. If you
try the "gitk" program, it visualizes this rather well)

The "upstream" branch on git.debian.org still points to the
"upstream/2.7.10" tag.

If you like, I could try doing a local "git import-orig" on top of that,
and see if a merge will create a direct "upstream" history line which
can be merged into our "master".

-- 
Stig Sandbeck Mathisen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/attachments/20120224/c4bae79e/attachment.pgp>