> I think this is what we want.
Hmm.
> Updating ChangeLog is already quite time consuming
Yes. This is matter of fact, and it won't become less. I really
insist on detailed informations which make clear what has changed and
why.
> and I already experienced a few frustrating merge conflict with it
> when pulling upstream into my own branches (these happen very easily
> when you updated a file that has been modified in the pulled
> upstream).
IMHO, conflicts in the ChangeLog file are rather easy to fix.
> So I guess we probably need to find a middle ground, i.e. generate
> an automatic ChangeLog from "git log" and use a different file to
> document the changes (one that would not necessarily need the list
> of all files modified, etc..).
I do not oppose in principle, but I really doubt that committers have
the discipline to really write concise commit messages (at least you
sometimes tend to be a bit sloppy :-) On the other hand, `gitk' is an
invaluable tool, and showing the code differences says more than
anything else. If we abandon the ChangeLog file, we should do it
completely, *not* autogenerating it. A developer downloads the whole
git repository; she can then easily say `gitk' or `git log'. All
others are rather not interested in the ChangeLog at all, I think.
> Maybe we need another file like docs/INTERNAL-CHANGES.TXT ?
Please no. This is even more work.
IMHO we should force everyone to commit *small* chunks, split into
easily readable code fragments. This would help more than anything
else.
Werner
_______________________________________________
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
