Dne St 5. května 2010 08:54:01 Wolfgang Denk napsal(a):
Dear Kim Phillips,
In message 20100504192544.6506945d.kim.phillips@freescale.com you wrote:
It is assumed that this file's only purpose is to serve non-git users downloading u-boot project source in the form of a tarball release. If that is the case, then the generation of the CHANGELOG file should occur at tarball release generation time, and not consume duplicate history,
Can you recommend a way how such auto-generation / inclusion would be done?
Currently I'm using something like this:
$ V=2010.03 $ PREFIX=u-boot-${V}
git log > CHANGELOG
$ git archive --format=tar --prefix=${PREFIX}/ v${V} | \
tar -r CHANGELOG or something ?
bzip2 -v9 >~/tmp/${PREFIX}.tar.bz2
How could this be made to include a non-git-controlled CHANGELOG?
Slowing things down? C'me on.
maybe not git grep performance-wise (yet), but on a frequently-occurring search term, when we have to visually sift through and page down through a large number of CHANGELOG hits (that invariably show up first), then yes, I consider that a development-time barrier.
So what about git performance? A "grep foobar CHANGELOG" is significantly faster than a "git log --grep=foobar", isn't it?
NAK. My position about these files has not changed.
Please reconsider: u-boot has no need to be 'special' in this area, and this file's continued existence is a lingering harassment for developers such as myself.
Harassment? Strong words. I am seriously listening to your arguments, but so far I feel that there is a lot of emotion in your message but only few arguments I can follow.
Yup
I can understand that you see little use in this file, and even that occasionally it comes into your way.
On the other hand, I regularly use this file, because it speeds up my work.
In addition to the arguments already mentioned here is another reason why I would like to keep this file in place: Quite often we have to work with copies of the U-Boot source tree that do not contain any good information about which version they might have been derived from; the CHANGELOG at least gives an idea about the time frame.
How would you try such identification?
Best regards,
Wolfgang Denk