Re: Separate branch for experimental)
Joey Hess wrote: > When I try git-dch, it outputs too many lines like > * fix dumb mistake > * no, my fix for dumb mistake was a dumb mistake, actually > :-) I'm sure this looks better if all development on the release branch > is carefully constrained to consolodated changesets that don't reflect > the underlying development mess^Wprocess. Again, that may work well for some > projects, but is seriously ambitious for others. I think it makes sense to optimise for projects with a good change management policy. The approach I described still allows for customising how the debian/changelog appears by copying it to debian/changelog.in, should the upstream changelog from the commit tracking prove worthless. Sam. ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
On ke, 2007-10-31 at 19:02 -0400, Joey Hess wrote: > Lars Wirzenius wrote: > > Soon after I switched from CVS to Bazaar (bzr), I stopped using > > changelog files. Instead, before I make a release, I update a NEWS file > > which summarizes the changes since the previous release, and also add a > > dump of the commit messages (bzr log --long --verbose, more or less) to > > sit next the tarball, but that is not included in the package itself. > > > > So far I'm happy with this solution. > > That offloads the work of writing a good changelog onto the person who > makes the release. That is possibly true. In multi-person projects, I'd have a rule saying the committer must also write a good commit message. If a NEWS file isn't required (it is a higher-level document than a changelog), the commit message dump should suffice as a replacement for a changelog, in my opinion. But since I mostly work alone on my projects, I don't have much experience with this. I think the bzr developers use something similar, though augmented by a habit of having anyone who commits something that should be mentioned in NEWS also update the NEWS file. Lots of different ways of doing things, of course. Anything that works well is good. :) ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
Joey Hess wrote: > BTW, the main merge issue with merging changelogs should be the > " -- Author Name " line of the changelog. Avoid changing that line > and changelogs merge pretty well. Turns out that dch recently got a -t option that avoids changing that line. -- see shy jo signature.asc Description: Digital signature ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
Lars Wirzenius wrote: > Soon after I switched from CVS to Bazaar (bzr), I stopped using > changelog files. Instead, before I make a release, I update a NEWS file > which summarizes the changes since the previous release, and also add a > dump of the commit messages (bzr log --long --verbose, more or less) to > sit next the tarball, but that is not included in the package itself. > > So far I'm happy with this solution. That offloads the work of writing a good changelog onto the person who makes the release. Probably works well for packages maintained by one person, less well for packages maintained by lots of people all making changes, and not very well at all for certian teams (ie d-i and pkg-perl) where changes are made by some people, and released by often entirely different people, who often need to release many packages all at once. When I try git-dch, it outputs too many lines like * fix dumb mistake * no, my fix for dumb mistake was a dumb mistake, actually :-) I'm sure this looks better if all development on the release branch is carefully constrained to consolodated changesets that don't reflect the underlying development mess^Wprocess. Again, that may work well for some projects, but is seriously ambitious for others. BTW, the main merge issue with merging changelogs should be the " -- Author Name " line of the changelog. Avoid changing that line and changelogs merge pretty well. Since the main reason dch updates that line is so it can keep track of who made the last change (so it can put it in "[ Author Name ]" form in the changelog), maybe there is a way to change dch to not modify that line (except for with --release), and store the author info elsewhere. -- see shy jo signature.asc Description: Digital signature ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
On ke, 2007-10-31 at 21:55 +0100, martin f krafft wrote: > also sprach Kumar Appaiah <[EMAIL PROTECTED]> [2007.10.31.0219 +0100]: > > 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? > > We need to get rid of the changelog-as-a-file concept and build the > changelog from commit log entries in the build branch. git-dch (part > of git-buildpackage), which I have not yet tried, might be a step in > the right direction. See Sam's response. Soon after I switched from CVS to Bazaar (bzr), I stopped using changelog files. Instead, before I make a release, I update a NEWS file which summarizes the changes since the previous release, and also add a dump of the commit messages (bzr log --long --verbose, more or less) to sit next the tarball, but that is not included in the package itself. So far I'm happy with this solution. ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
also sprach Kumar Appaiah <[EMAIL PROTECTED]> [2007.10.31.0219 +0100]: > 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? We need to get rid of the changelog-as-a-file concept and build the changelog from commit log entries in the build branch. git-dch (part of git-buildpackage), which I have not yet tried, might be a step in the right direction. See Sam's response. -- martin | http://madduck.net/ | http://two.sentenc.es/ "good advice is something a man gives when he is too old to set a bad example. -- la rouchefoucauld spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
On Wed, Oct 31, 2007 at 02:31:38PM +1300, Sam Vilain wrote: > 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 OK, that is actually right, and I will now use this method. > 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; [snip] The pseudocode is very nice, and I'll work on adding it into my current approach. Thanks a lot for that! > 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. I think I would reinvent the wheel, and get back to you for help when I need it. Thanks a lot for all the thoughtful answers. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
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 then. 2. Find the first tag in the history since the last changelogged release Something like 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 | git shortlog)" 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 | git shortlog)" 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. Sam. ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
On Wed, Oct 31, 2007 at 01:40:11PM +1300, Sam Vilain wrote: > As Martin suggests you may just be able to get away with a merge. This seems to be quite OK, and themos straightforward method. Thanks for this. > That will possibly leave you with a merge conflict. In that case, > git-mergetool, git-gui and gitk --merge are your friends. Get it the > way you want, and git-commit. Update the debian/changelog as you see > fit and commit again. 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? Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
Kumar Appaiah wrote: > I have a package, which is meant for unstable. Now, because of the > gfortran transition, I want to upload the package, with modfications > to experimental. This involves renaming some .install and .docs files > in debian/, and editing the control file. OK till now, except that if > upstream makes a new release, I'll have to somehow revert the changes > to the older versions (pre-exeperimental upload), and keep the > changelog with the experimental entry intact, switch back, and create > a new experimental upload. This reverting, re-reverting etc. is the > part I want to see how to solve. > > Right now, I have only two branches, upstream and master, as I adopted > a rather simplistic approach to packaging. Could you suggest a way by > which this problem can be "decently" handled with branches (or > otherwise) in git? As Martin suggests you may just be able to get away with a merge. You make a new branch, call it bob or something like that. It doesn't matter, git branches flap in the wind with no real permanence, only occasionally appearing in automatically generated merge comments. eg git-checkout -b bob upstream Then put the new upstream package in. There are lots of ways to do this. This is one simple way. git-rm \* tar xzvf ../upstream-package.tar.gz mv upstream-package/* . rmdir upstream-package git-add . git-commit -m "New upstream version" Then, the easiest thing to do is to merge the old branch on top of that. git-merge master That will possibly leave you with a merge conflict. In that case, git-mergetool, git-gui and gitk --merge are your friends. Get it the way you want, and git-commit. Update the debian/changelog as you see fit and commit again. Sam. ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
Re: Separate branch for experimental)
also sprach Kumar Appaiah <[EMAIL PROTECTED]> [2007.10.30.1117 +0100]: > upstream makes a new release, I'll have to somehow revert the changes > to the older versions (pre-exeperimental upload), and keep the > changelog with the experimental entry intact, switch back, and create > a new experimental upload. This reverting, re-reverting etc. is the > part I want to see how to solve. Why won't a simple merge of upstream not do? All the changes you made are Debian-specific, or so it seems. Either a merge or a rebase, depending on your approach. -- martin | http://madduck.net/ | http://two.sentenc.es/ "the truth is rarely pure and never simple. modern life would be very tedious if it were either, and modern literature a complete impossibility!" -- oscar wilde spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
