On Mon, 2009-04-20 at 18:16 -0700, Jesse Keating wrote: > On Mon, 2009-04-20 at 16:18 -0700, Adam Williamson wrote: > > so you manually write the one with extra bumph that could easily be > > automatically generated, and then use that to produce the one which > > *doesn't* have extra bumph that could easily be automatically > > generated? :) > > I'm not sure I follow. CVS sort of lends itself to doing a days worth > of changes in one commit, so it's work work work, documenting work as > you go in the .spec file (although often it's just "new upstream > release" or "patch for $foo", then when you're ready to make it happen > it's "make clog && cvs commit -F clog && make tag build" > > Now if we were using a scm that was more geared toward commit as you go, > we might consider something different, but even then what you want to > expose to users isn't necessarily the same thing you want to document > when doing SCM commits. Here is where git is neat with the shortlog, > where you oneline your change, but then can expand upon it in another > paragraph that will be seen when looking at the git log, but won't be > seen if you do a simple short log (like say for stuffing in a .spec > file). OK, I see what you're driving at now. But you missed one point I wrote on the issue of where you want the two to be different - you can just implement a keyword for commit messages which causes it not to go into the RPM changelog, viz: cvs commit -m "this commit message will go into the RPM changelog" cvs commit -m "SILENT: but this one won't!" pretty simple. However, now I get your point, I agree that the issue of switching SCMs would be more significant and an appropriate place to look at this issue too. CVS is pretty creaky these days. FWIW, when I was working on packages at That Other Place, I would work work work all day and then commit too, but with a commit message that looked like this: - one change - another change - yet another change - SILENT: a trivial change i don't want to go in the RPM changelog and that all got parsed correctly into the RPM changelog, in the way you'd expect it to. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
