On Thu, 12 Oct 2006, Linus Torvalds wrote: > > Why? That's just stupid. Btw, let me explain that strong statement, because it _is_ a strong statement, but it's true. The problem with trying to generate a changelog entry at commit time is that it is fundamentally a broken concept in a distributed environment. What happens at a merge event? Sure, you can have special merge magic to try to sort out the mess, but it _is_ a mess. You can make things "work", but you can never actually make the result really make _sense_. The changelog is fundamentally a serialization of something that wasn't serial. Now, the same serialization problem obviously exists when you auto-generate the changelog file when doing a release tar-ball or something like that, but at that point you basically "fix" it in time, so at that point the changelog actually makes sense. It also turns out that in many situations, you can sort the result in other ways: the shortlog format, for example, is often superior to the default "git log" ordering, just because sorting things by person tends to actually result in a better view of what changed (it tells you something new: clumping by author not onyl tends to clump similar commits together and thus tell more of a "story", but it also has the added advantage of telling people who does what). Generating things after-the-fact would also allow ordering things by what files (or subdirectories) they touch, although we've never done such a script. I do that quite often privately by just restricting the log to certain subsystems, though, and it's a damn useful thing to have. I would not be surprised at all if it might make sense to actually do a "tar-ball" changelog that way for certain projects - especially if they have clearly separated sub-components. [ Btw, this whole "do things by pathname" has been so successful, that I've come to realize that I would probably never accept an SCM that doesn't allow something like that. Being able to do gitk some/random/set of/directories and/files is just _incredibly_ useful. Maybe others don't do it as much as I do, but as a top-level maintainer, being able to look at history from the viewpoint of just a random subset of the tree is incredibly powerful. I very strongly suspect that doing logs that way is often a good idea too. ] Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html