On Wed, 5 May 2010 08:54:01 +0200 Wolfgang Denk wd@denx.de wrote:
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 archive --format=tar --prefix=${PREFIX}/ v${V} | \
bzip2 -v9 >~/tmp/${PREFIX}.tar.bz2
How could this be made to include a non-git-controlled CHANGELOG?
(see below)
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?
true, but I find that git log runs well after it is run once and everything is loaded in the cache.
Also, if I'm git grepping in the u-boot git tree, I want to grep the source, not the git log.
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.
you are right; bad choice of words; I meant something milder - more along the lines of 'annoyance'.
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?
it appears that the granularity of CHANGELOG updates is equal to that of VERSION, PATCHLEVEL, and EXTRAVERSION assignments in the root Makefile; so presumably one can refer to those instead.
For exact per-export granularity, one can do something like this:
cd u-boot echo '$Format:%H$' > snapshot.commit git add snapshot.commit && git commit -m 'add snapshot.commit file' echo 'snapshot.commit' > .git/info/attributes git archive --format=tar --prefix=${PREFIX}/ <commit> ...
...the resultant tarball's snapshot.commit file will contain the value of the sha id representing commit <commit>.
for more info, see the gitattributes manpage and the list of placeholders in the PRETTY FORMATS section of the git log manpage.
Kim