Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Jim Ramsay <lack@g.o>
Subject: Re: [git migration] The problem of ChangeLog generation
Date: Sun, 2 May 2010 15:13:50 +0000
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)
Attachment:
pgpSjctx2CorV.pgp (PGP signature)
References:
[git migration] The problem of ChangeLog generation
-- Nirbheek Chauhan
Re: [git migration] The problem of ChangeLog generation
-- Peter Volkov
Re: [git migration] The problem of ChangeLog generation
-- Nirbheek Chauhan
Re: [git migration] The problem of ChangeLog generation
-- Peter Volkov
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [git migration] The problem of ChangeLog generation
Next by thread:
Re: [git migration] The problem of ChangeLog generation
Previous by date:
Re: A policy to support random superuser account names
Next by date:
Re: A policy to support random superuser account names


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.