Peter Volkov wrote: > ?? ??????, 13/04/2010 ?? 17:18 +0530, Nirbheek Chauhan ??????????: > > The traditional ChangeLog that is currently employed in gentoo-x86 > > (and in other projects) is simply an ugly hack > > The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used > in other projects is
I think another very important distinction (that you imply below, but I want to specifically point out here) is that we have *many* per-project ChangeLogs whereas most other projects have a *single* monolithic ChangeLog. > > Think of it like this: if you make a typo in a commit message, or > > forget to add something; you can't change it after you've published > > the commit (cvs/svn commit or git push) to the world. > > And then it's better to keep ChangeLogs. For developers it was never a > problem to script `echangelog "log" && repoman commit -m "log"` and > conflict resolution is really not that hard with git. In spirit of > Gentoo, it's better to write some tool to update Manifests after > conflict resolution instead of making ChangeLogs less useful for those > who uses them. This is a very good point regarding ease of conflict resolution. Further to my other point above, the traditional ChangeLog ugliness really only hits you with a centralized setup+git if *everyone* is editing the *same* ChangeLog: If every commit touches the same file in the same place (ie, prepending to a ChangeLog file in the same location), you are guaranteed to have collisions every time you pull a new version of the file. This is why most projects with a single monolithic changelog auto-generate them, or perhaps just craft them at release time. Our case, though it is a centralized repository model, is quite different. The chance of collisions in a package-specific ChangeLog is, as it is today with CVS, pretty unlikely. In fact, I think the only time it usually happens to me is when an arch stabilizes my package while I'm making a change, and these are very easy to fix. (In fact, it may be possible to help git out with this specific ChangeLog situation by using a "custom merge driver", see GITATTRIBUTES(5) for details, though deployment of a custom merge driver can be tricky) > BTW as for profiles ChangeLogs... May be it's better to generate them. That's another important distinction and probably a good idea. I think those profile ChangeLogs are also not as user-facing as the per-package ones, so an autogenerated one makes a lot of sense. -- Jim Ramsay Gentoo/Linux Developer (rox/fluxbox/gkrellm)
pgpnnsBkS27K2.pgp
Description: PGP signature
