Kumar Appaiah wrote:
> All this is just perfect. I still have just one issue. Can I share the
> changelog across branches? I mean, can I separate the changelog alone
> into a separate branch, and merge it into master and experimental (a
> new branch) before the build?
That sounds odd, because if you did that you would be distributing a
changelog for a particular release, that has entries referring to other
releases. Perhaps you can give an example?
Note that with those commands I gave the changelog would be preserved.
However it is my personal opinion that the debian changelog is best
generated from the version control history, and not stored in version
control. ie, debian/changelog should be in .gitignore
For instance, if you renamed the old debian/changelog to
debian/changelog.in, and made a practice of making tags for named
revisions, then you could generate the changelog file.
The psuedocode is this;
0. if debian/changelog does not exist, but debian/changelog.in does,
copy one to the other
1. get the tag corresponding to the last release described in the
debian/changelog that is actually a tag. Discard everything since
2. Find the first tag in the history since the last changelogged
git-rev-list $last_release..HEAD | tac |
git name-rev --tags --stdin | grep -v '~' | head -1
3. list all the revisions in that range, and make a debian changelog
entry for it with dch
dch -v $next_release "$(git log $last_release..$next_release |
4. repeat steps 1 to 3 until you reach the most recent tag
5. make the current release of the package something based on the
output of $(git describe HEAD), and put it into the changelog, eg
version=$(git describe HEAD)
dch -v $version "$(git log $last_release..HEAD |
I'm not sure if that's what any of the other git package management
tools do. We've got some working code to do this for our own packages
here at Catalyst somewhere if you're interested.
vcs-pkg mailing list