On Tue, Jul 17, 2012 at 02:17:59AM +0200, Kacper Kornet wrote: > > > But that would be not 'totally unordered'. > > > GIT history is just not linear > > It's the different history: take %changelog as NEWS > > and commit messages as CHANGELOG. The latter is for > > developers while the former is for users (sysadmins).
(at least that's my take at the problem, of course) > > And for a given package there's sense to make sure > > its git history *is* linear. > > See e.g. http://git.altlinux.org/gears/r/rpm.git > Could you elaborate a little more how do you do it? I write my %changelogs by hand since that allows me the luxury of proper commits with explanations regarding developer side (like if I was documenting things for myself reading it again a year or two later), *and* yet allows me the luxury of reading terse enough changelogs via rpm -q --lastchange :) > I see that changelog entries are still present in spec files, Yes; that's both good and bad, not sure if openSUSE or PLD approach wins for me (but it's only a personal opinion!). Generated data tend to be less useful due to lower SNR. There's a gear-commit(1) utility for doing the opposite, generating commit messages from %changelog records: http://docs.altlinux.org/manpages/gear-commit.1.html > and they are generated from commitlogs of tagged commits. Might be but not enforced to. > But how does these commitlogs are generated. Are they some > short of condensed 'git log' from the last tag? There's gear-changelog(1) utility developed for the storage format born at ALT some six or seven years ago: http://docs.altlinux.org/manpages/gear-changelog.1.html http://docs.altlinux.org/manpages/gear-changelog-rules.5.html http://www.altlinux.org/Gear/changelog [ru] Maybe it serves as a good starting point for PLD's one. Just in case, server side has girar- prefix: http://git.altlinux.org/people/ldv/packages/?s=girar > And how to you force that the tagged commits are in > chronological order? The next "buildable" tag has to inherit from the previous successfully built tag for the successfully built new package to be allowed through to the repository. There's considerable work by Alexey Tourbin in place regarding the repository consistency, I can give a link to a whitepaper in Russian (proshu pana). DISCLAIMER: there are some troubles with the (almost) free-form git repos that gear supports for package generation; if interested, I can try to sum these up. In short, getting a repo into a state when no sane Patch: series could be extracted and stored in srpm is pretty easy, it's enough to be lazy and fix things in-place... (ALT used to be a meaningful source of patches but this got hit pretty heavily by megapatches or even %name-%version-%release.tar files incorporating all the upstream code and patches/commits in nearby git branches). And that's a problem. By the way, *thank you* PLD folks for your nice specs with predictable URLs as well as for nice standalone patches. -- ---- WBR, Michael Shigorin <m...@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en