On Thu, Jun 2, 2011 at 6:29 PM, Fabian Groffen <grob...@gentoo.org> wrote:
> On 02-06-2011 17:15:11 +0530, Nirbheek Chauhan wrote:
>> > - no discussion on what to include or not (everything is in there)
>>
>> In git, we can make git log skip commit messages while generating the
>> ChangeLog, so this is incorrect. See section "Commit Limiting" in git
>> log --help.
>
> Assuming this is actually desirable, what rules would you suggest here?
>
Mostly only the trivial commits should be skipped. We should refer to
the other thread to decide what this consists of.
>> > Simple cons I see mentioned:
>> > - useless information on removals of ebuilds/files
>> > - useless information on whitespace changes
>>
>> None of these are valid with Commit Limiting and a tag such as
>> '[trivial]' in the commit message subject.
>
> By allowing this, "[trivial] old" is bringing you back to current policy
> ("commont sense") problems.
>
Yes, except that now it doesn't affect developers, and will result in
much less controversy. It certainly shouldn't come to forced
retirement. I don't see why we should bombard users with trivial
commits for political reasons...
>> Infact, if you do the same experiment on the openrc ChangeLog, you'll
>> see that it's too much work to regenerate the current ChangeLog
>> because a few commits managed to change the encoding of names in the
>> file, and a reverse-patch had to be applied to fix it. A number of
>> developers have made this mistake, and it shows up across the tree.
>
> I just created openrc's ChangeLog (attached to this mail). In what way
> exactly is it too much work? It's just a ChangeLog like many others, e.g.:
>
Ah, you don't include changes to ChangeLog as a part of your script.
Nevermind then :)
>> In git, there's no harm with making commit messages verbose, so we
>
> Why is this harmful with the current system?
>
Because it results in double the wasted space inside the repository.
Also, git is orders of magnitude better at compressing commit
messages, so the cost is massively lower.
>> > - a clear policy is necessary on what is going in the ChangeLog and what
>> > not (like the current "common sense" discussions going on and the
>> > updated devmanual)
>>
>> However, with git the issue is simplified because then developers will
>> stop relying on ChangeLogs for information, and ChangeLogs will be
>> used entirely to convey information to users.
>
> I don't see how that simplifies. I only see how that would completely
> change things/intents. Can you elaborate?
>
It simplifies things because most of the current situation arises from
shoe-horning of user as well as developer needs into a feature that is
supposed to be primarily user-oriented.
With CVS: "Trivial" changes that weren't documented in ChangeLog cause
breakage. cvs log/diff is too slow/hard to use, that delays
identification and fixing of breakage, and leads to a stricter policy
on ChangeLog updation.
With git: Changes that were marked [Trivial] in the commit message
cause breakage. git log, and you're done. There's no ChangeLog in the
git repo anyway, so no one will use ChangeLogs for this information.
This leaves us with user-oriented information. 99.99% of users won't
care about some commit messages being skipped from ChangeLog. Those
that do can clone the git repo, or sources.gentoo.org (which will be
faster with git). This doesn't mean we should skip *all* information
and not care at all. Just that the situation is less controversial
than before.
Cheers,
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
