> 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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel