Re: cg-commit does not run pre-commit hook?

[Linus Torvalds <torvalds@osdl.org>]

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