[U-Boot] [PATCH 2/2] remove main CHANGELOG file
CHANGELOG is a duplicate of the u-boot project's git log: remove it.
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, slowing things down and polluting grep match results for u-boot developers using git.
u-boot project git history goes back to before u-boot 0.1.0, so remove CHANGELOG-before-U-Boot-1.1.5 file too.
Signed-off-by: Kim Phillips kim.phillips@freescale.com --- CHANGELOG |83736 ----------------------------------------- CHANGELOG-before-U-Boot-1.1.5 | 5607 --- 2 files changed, 0 insertions(+), 89343 deletions(-) delete mode 100644 CHANGELOG delete mode 100644 CHANGELOG-before-U-Boot-1.1.5
diff --git a/CHANGELOG b/CHANGELOG deleted file mode 100644 index d4cd8f1..0000000 --- a/CHANGELOG +++ /dev/null @@ -1,83736 +0,0 @@ -commit 8e64d6efd8d778a5f83d8bff9cd273a86dcc182f -Author: Heiko Schocher hs@denx.de -Date: Wed Mar 31 08:34:51 2010 +0200 - - net, doc: How to setup MAC address correctly -
<deleted rest of patch due to excessive size, but something like this should do it:
git am <this-message>; git rm CHANGELOG*; git add -u; git commit
Dear Kim Phillips,
In message 20100413211604.66841557.kim.phillips@freescale.com you wrote:
CHANGELOG is a duplicate of the u-boot project's git log: remove it.
No. Please re-read the archive why this file is kept.
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, slowing things down and polluting grep match results for u-boot developers using git.
Slowing things down? C'me on.
Polluting grep results? Then exclude this file from grepping...
u-boot project git history goes back to before u-boot 0.1.0, so remove CHANGELOG-before-U-Boot-1.1.5 file too.
NAK. My position about these files has not changed.
Best regards,
Wolfgang Denk
On Tue, 4 May 2010 23:41:40 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Kim Phillips,
In message 20100413211604.66841557.kim.phillips@freescale.com you wrote:
CHANGELOG is a duplicate of the u-boot project's git log: remove it.
No. Please re-read the archive why this file is kept.
looking in the u-boot archives, found this very old thread (which I assume is the result of CHANGELOG causing a merge conflict way back when):
Subject: [U-Boot-Users] Proposed CHANGELOG Generation Helpers Date: Thu, 12 Oct 2006 20:14:30 -0500
and in Message-Id: 20061013095221.AC2B1353C95@atlas.denx.de, you write:
So since I seem to be the only person on this planet who likes to have this CHANGELOG file, and it has caused so much trouble already I suggest the following procedure:
...
(2) rename CHANGELOG into CHANGELOG.OLD, and start a new CHANGELOG which gets automatically generated using the command above or a variation thereof.
Note: nobody needs to take care of this file. It is purely for my own private needs, and I will manage it on my own. Everybody else can just ignore the existence of this file.
which doesn't do a good job of explaining why you keep this file.
More interestingly, in this message:
http://article.gmane.org/gmane.comp.version-control.git/28785
you write:
True, as long as you can work within the SCM. The changelog file I'm talking about is mostly for people who just work with exported trees (for example, when they download a tarball).
which almost supports what I write in the commit message:
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,
..which was already suggested to you by Josef Weidendorfer:
http://article.gmane.org/gmane.comp.version-control.git/28790
and further reinforced by Linus Torvalds, here:
http://article.gmane.org/gmane.comp.version-control.git/28789
slowing things down and polluting grep match results for u-boot developers using git.
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.
Polluting grep results? Then exclude this file from grepping...
that's a PITA, and besides, that's what this patch does, and, afaict, at no loss on your part.
u-boot project git history goes back to before u-boot 0.1.0, so remove CHANGELOG-before-U-Boot-1.1.5 file too.
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.
Best regards,
Kim
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?
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.
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
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
Dear Marek,
In message 201005051551.47704.marek.vasut@gmail.com you wrote:
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 ?
Using a plain "CHANGELOG" here a misses the "${PREFIX}/" part, so I would have to create this directory first [and probably a tmp directory to put it in first to avoid potential name conflicts], then create the CHANGELOG file there, then append it to the archive, then clean everything up.
Is there a more elegant way?
Best regards,
Wolfgang Denk
On Wed, May 5, 2010 at 9:17 AM, Wolfgang Denk wd@denx.de wrote:
Using a plain "CHANGELOG" here a misses the "${PREFIX}/" part, so I would have to create this directory first [and probably a tmp directory to put it in first to avoid potential name conflicts], then create the CHANGELOG file there, then append it to the archive, then clean everything up.
I can't say if there is a more elegant way of doing this, but if there isn't, can't you automate the above steps with a script?
I agree with Kim. Is there anyone besides you who uses CHANGELOG? If not, then maybe it should be deleted from the repository. I don't see why you can't run a script to regenerate it when you need it.
Dear Timur Tabi,
In message n2med82fe3e1005050756i7f91e365z91ce1bf19d382537@mail.gmail.com you wrote:
I agree with Kim. Is there anyone besides you who uses CHANGELOG? If not, then maybe it should be deleted from the repository. I don't see why you can't run a script to regenerate it when you need it.
The thing is that I use it all the time. grepping there is often more efficient for me then using git log --grep.
Does it hurt you?
Best regards,
Wolfgang Denk
Hi Wolfgang,
In message n2med82fe3e1005050756i7f91e365z91ce1bf19d382537@mail.gmail.com you wrote:
I agree with Kim. Is there anyone besides you who uses CHANGELOG? If not, then maybe it should be deleted from the repository. I don't see why you can't run a script to regenerate it when you need it.
The thing is that I use it all the time. grepping there is often more efficient for me then using git log --grep.
Could you describe what you use CHANGELOG for? I often look at logs, but 99% of the time its a log of a specific file or directory to trace a bug, see why feature X was added, etc. I rarely look at the repositories entire log, and if I do, I use 'git log'. Although 'git log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which may be slightly out of date.
If you do prefer the speed of looking at a CHANGELOG file, its easy to generate one when you require it.
Does it hurt you?
'hurt' is a strong word, but it certainly annoys me too. Eg: - Every time someone greps they have to visually ignore the CHANGELOG file hits, or alternately make a grep wrapper script specific to u-boot that strips out CHANGELOG hits. - Its a duplication of data that's already stored in the repository history. Who likes duplicated data? - For any change that is automated via a script/grep/sed/etc one needs to filter out the CHANGELOG files.
I don't know if this is much cleaner, but: $ V=2010.03 $ PREFIX=u-boot-${V} $ git archive --format=tar --prefix=${PREFIX}/ v${V} | tar -xC ~/tmp $ git log > ~/tmp/${PREFIX}/CHANGELOG $ tar -cj -f ~/tmp/${PREFIX}.tar.bz2 -C ~/tmp/ ${PREFIX} $ rm -fr ~/tmp/${PREFIX}
We could also follow Linux's lead and upload the CHANGELOG as a separate file from the source. eg there would be a CHANGELOG-{V} for each released U-Boot version detailing only what changed since the last release (www.kernel.org/pub/linux/kernel/v2.6/), or alternatively one mega-CHANGELOG like we're doing now if people prefer.
Best, Peter
Dear Peter Tyser,
In message 1273075406.2451.4225.camel@localhost.localdomain you wrote:
Could you describe what you use CHANGELOG for? I often look at logs, but 99% of the time its a log of a specific file or directory to trace a bug, see why feature X was added, etc. I rarely look at the repositories entire log, and if I do, I use 'git log'. Although 'git log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which may be slightly out of date.
Most frequently I use it in combination with some form of grep command (grep, agrep etc.); sometimes I use it in vi/view for manual searching / reading.
Here are a few reasons where I prefer accessing the CHANGELOG over running "git log --grep":
1) it's faster:
-> time grep foobar CHANGELOG
real 0m0.005s user 0m0.004s sys 0m0.001s
-> time git log --grep=foobar >/dev/null
real 0m0.240s user 0m0.219s sys 0m0.021s
2) it's more efficient:
-> strace -f grep foobar CHANGELOG 2>&1 >/dev/null | wc -l 143 -> strace -f git log --grep=foobar 2>&1 >/dev/null | wc -l 2494
3) it delivers only the lines I cactually search for, while "git log --grep" always spills out the whole commit message:
-> grep MPC512x CHANGELOG | wc -l 24 -> git log --grep=MPC512x | wc -l 272
4) I can use arbitrary grep options. I am not aware of a git equivalent to, say:
-> grep -C2 --color string CHANGELOG
5) I can use other tools to process the messages, like agrep for fuzzy searching; I frequently use this when checking if a specific patch has been applied - too many times a plain text search does not work because the committer manually edited the commit message to fix typos etc. I am not aware of a git equivalent to, say:
-> agrep -2 -i string CHANGELOG
This is probably my most frequently used command
If you do prefer the speed of looking at a CHANGELOG file, its easy to generate one when you require it.
Yes, I know. But I also want it available to those who don't use git, so it should to be included in the release tarball, and in the auto-generated tarballs when using the "snapshot" links on the web interface; for example try:
-> wget -O u-boot.tgz 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
Does it hurt you?
'hurt' is a strong word, but it certainly annoys me too. Eg:
- Every time someone greps they have to visually ignore the CHANGELOG
file hits, or alternately make a grep wrapper script specific to u-boot that strips out CHANGELOG hits.
Strange. If I ever run into such a problem then so infrequently that I don't notice it. I guess this is because I usually only grep in specific file types (like "*.[Sch]" or so).
- Its a duplication of data that's already stored in the repository
history. Who likes duplicated data?
In the strict sense, all the checked out files are duplicated data.
- For any change that is automated via a script/grep/sed/etc one needs
to filter out the CHANGELOG files.
You probably need to exclude a number of other files as well?
We could also follow Linux's lead and upload the CHANGELOG as a separate file from the source. eg there would be a CHANGELOG-{V} for each released U-Boot version detailing only what changed since the last release (www.kernel.org/pub/linux/kernel/v2.6/), or alternatively one mega-CHANGELOG like we're doing now if people prefer.
I would like to keep the CHANGELOG as part of tarballs, including auto-generated ones.
Best regards,
Wolfgang Denk
On 05/05/2010 02:05 PM, Wolfgang Denk wrote:
Dear Peter Tyser,
In message1273075406.2451.4225.camel@localhost.localdomain you wrote:
Could you describe what you use CHANGELOG for? I often look at logs, but 99% of the time its a log of a specific file or directory to trace a bug, see why feature X was added, etc. I rarely look at the repositories entire log, and if I do, I use 'git log'. Although 'git log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which may be slightly out of date.
Most frequently I use it in combination with some form of grep command (grep, agrep etc.); sometimes I use it in vi/view for manual searching / reading.
Here are a few reasons where I prefer accessing the CHANGELOG over running "git log --grep":
it's faster:
-> time grep foobar CHANGELOG
real 0m0.005s user 0m0.004s sys 0m0.001s
-> time git log --grep=foobar>/dev/null
real 0m0.240s user 0m0.219s sys 0m0.021s
Surely the extra quarter second is not too significant compared to the time it takes to formulate the query and examine the results.
it's more efficient:
-> strace -f grep foobar CHANGELOG 2>&1>/dev/null | wc -l 143 -> strace -f git log --grep=foobar 2>&1>/dev/null | wc -l 2494
It also requires that a cache be maintained just for this purpose.
it delivers only the lines I cactually search for, while "git log --grep" always spills out the whole commit message:
-> grep MPC512x CHANGELOG | wc -l 24 -> git log --grep=MPC512x | wc -l 272
$ git log | grep MPC512x | wc -l 24
Likewise for grep options and alternate tools.
Or if you really want, you could do this locally, and put CHANGELOG in .gitignore:
$ time git log > CHANGELOG
real 0m0.453s user 0m0.350s sys 0m0.050s
You could even have a cron job keep it up to date. :-)
-Scott
Dear Scott Wood,
In message 4BE1CACE.6040005@freescale.com you wrote:
Surely the extra quarter second is not too significant compared to the time it takes to formulate the query and examine the results.
The requests are often generated by some script, and there may be tens of them - enough that the 'git log' versions takes several seconds.
it's more efficient:
-> strace -f grep foobar CHANGELOG 2>&1>/dev/null | wc -l 143 -> strace -f git log --grep=foobar 2>&1>/dev/null | wc -l 2494
It also requires that a cache be maintained just for this purpose.
I can't parse that.
You could even have a cron job keep it up to date. :-)
Agreed. There are many, many possibilities.
Best regards,
Wolfgang Denk
Hi Wolfgang,
Could you describe what you use CHANGELOG for? I often look at logs, but 99% of the time its a log of a specific file or directory to trace a bug, see why feature X was added, etc. I rarely look at the repositories entire log, and if I do, I use 'git log'. Although 'git log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which may be slightly out of date.
Most frequently I use it in combination with some form of grep command (grep, agrep etc.); sometimes I use it in vi/view for manual searching / reading.
I still don't grasp what the common use of looking at U-Boot's entire changelog is. What are some common tasks that require grepping U-Boot's entire changelog? Are these tasks performed frequently enough that the extra <1 second 'git log' requires is bothersome?
<snip>
- it delivers only the lines I cactually search for, while "git log
- I can use arbitrary grep options. I am not aware of a git
- I can use other tools to process the messages, like agrep for fuzzy
As Scott mentioned, these can be solved via 'git grep | <cmd>'.
If you do prefer the speed of looking at a CHANGELOG file, its easy to generate one when you require it.
Yes, I know. But I also want it available to those who don't use git, so it should to be included in the release tarball, and in the auto-generated tarballs when using the "snapshot" links on the web interface; for example try:
-> wget -O u-boot.tgz 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
For snapshots, the CHANGELOG file is going to be out of date though. It'll only list the changes that occurred up to the previous release. This seems worse than not having a CHANGELOG at all as its actively misleading people as to what changes their source code has.
<snip>
- For any change that is automated via a script/grep/sed/etc one needs
to filter out the CHANGELOG files.
You probably need to exclude a number of other files as well?
I think in general you'd want to update all files other than CHANGELOG. As a concrete example, the following is a snippet from a script used for the recent directory reorganization:
git grep lib_$ARCH | grep -v CHANGELOG | sed s/:.*$// | uniq | xargs perl -pi -e "s/lib_$ARCH/arch/$ARCH/lib/"
I'll quit whining, just wanted to give my +1 for removing the changelog.
Best, Peter
Dear Peter Tyser,
In message 1273091842.2451.4563.camel@localhost.localdomain you wrote:
I still don't grasp what the common use of looking at U-Boot's entire changelog is. What are some common tasks that require grepping U-Boot's entire changelog? Are these tasks performed frequently enough that the extra <1 second 'git log' requires is bothersome?
I'm trying to maintain some awareness of open patches. For example, when I receive a pull request I mark all included patches as processed; sometimes this includes tracking down older versions of the patches, or commit messages that have been changed on the way. And yes, the <1 second delay is bothersome when doing this frequently enough.
-> wget -O u-boot.tgz 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
For snapshots, the CHANGELOG file is going to be out of date though. It'll only list the changes that occurred up to the previous release. This seems worse than not having a CHANGELOG at all as its actively misleading people as to what changes their source code has.
I disagree here. I find myself quite frequently in the situation that I have to identify the exact version some source tree has been derived from. Companies who maintain out-of-tree ports usually don't include any SCM information either. To me, the CHANGELOG is an extremely useful resource in such cases.
I'll quit whining, just wanted to give my +1 for removing the changelog.
I don't consider you whining. I am listening to the arguments. I am not convinced yet, though.
Best regards,
Wolfgang Denk
I'll quit whining, just wanted to give my +1 for removing the changelog.
I don't consider you whining. I am listening to the arguments. I am not convinced yet, though.
Well in that case, I'll chime in again:)
I still don't grasp what the common use of looking at U-Boot's entire changelog is. What are some common tasks that require grepping U-Boot's entire changelog? Are these tasks performed frequently enough that the extra <1 second 'git log' requires is bothersome?
I'm trying to maintain some awareness of open patches. For example, when I receive a pull request I mark all included patches as processed; sometimes this includes tracking down older versions of the patches, or commit messages that have been changed on the way. And yes, the <1 second delay is bothersome when doing this frequently enough.
I see, makes sense. This seems like a problem that is unique to you, as well as potentially a few other maintainers. I imagine the vast majority of developers rarely use the CHANGELOG file though. Would having maintainers create their own CHANGELOG files and/or use something like patchwork be acceptable?
-> wget -O u-boot.tgz 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
For snapshots, the CHANGELOG file is going to be out of date though. It'll only list the changes that occurred up to the previous release. This seems worse than not having a CHANGELOG at all as its actively misleading people as to what changes their source code has.
I disagree here. I find myself quite frequently in the situation that I have to identify the exact version some source tree has been derived from. Companies who maintain out-of-tree ports usually don't include any SCM information either. To me, the CHANGELOG is an extremely useful resource in such cases.
The CHANGELOG in a company's source tree won't provide any more information than the VERSION, PATCHLEVEL, and EXTRAVERSION in the Makefile though, right? Ie the CHANGELOG is only updated when the VERSION, PATCHLEVEL, and EXTRAVERSION are updated. Either way, it seems like an inexact method to determine the revision of the source code, and there should be a better solution so that you don't have to be a detective every time you get another vendor's source tree.
It seems bad to have an inaccurate CHANGELOG. For example if someone got a snapshot tarball a week before the last release, their CHANGELOG would be missing over 500 changes. In this case the CHANGELOG clearly isn't serving its intended purpose and could actually mislead someone, eg "I know commit XYZ introduces a bug, but the changelog says I don't have commit XYZ in my tree, so I'm bug free!". In reality there have been 500 commits the user is unaware of, including potentially commit XYZ they were trying to avoid.
OK, its a stretch, but I don't get the purpose of an inaccurate CHANGELOG in any case. Other than when the 1 commit that correlates to a tagged release is the the top-of-tree, the CHANGELOG is *never* up to date. It can only be believed if someone downloads an officially released tarball - otherwise it is most likely wrong.
Best, Peter
Dear Peter Tyser,
In message 1273095808.2451.4674.camel@localhost.localdomain you wrote:
I see, makes sense. This seems like a problem that is unique to you, as well as potentially a few other maintainers. I imagine the vast majority of developers rarely use the CHANGELOG file though. Would having maintainers create their own CHANGELOG files and/or use something like patchwork be acceptable?
As far as the patch processing is concerned, a dynamically generated file is perfectly good enough for me. If we can keep the "CHANGELOG" make target I have all I need here.
I disagree here. I find myself quite frequently in the situation that I have to identify the exact version some source tree has been derived from. Companies who maintain out-of-tree ports usually don't include any SCM information either. To me, the CHANGELOG is an extremely useful resource in such cases.
The CHANGELOG in a company's source tree won't provide any more information than the VERSION, PATCHLEVEL, and EXTRAVERSION in the Makefile though, right? Ie the CHANGELOG is only updated when the VERSION, PATCHLEVEL, and EXTRAVERSION are updated. Either way, it seems like an inexact method to determine the revision of the source code, and there should be a better solution so that you don't have to be a detective every time you get another vendor's source tree.
Thats's not quite right. I used to update CHANGELOG more frequently in the past.
It seems bad to have an inaccurate CHANGELOG. For example if someone got a snapshot tarball a week before the last release, their CHANGELOG would be missing over 500 changes. In this case the CHANGELOG clearly
Agreed. It was never perfect, but the best we (well, I) had.
OK, its a stretch, but I don't get the purpose of an inaccurate CHANGELOG in any case. Other than when the 1 commit that correlates to a tagged release is the the top-of-tree, the CHANGELOG is *never* up to date. It can only be believed if someone downloads an officially released tarball - otherwise it is most likely wrong.
Right. Well, Kim's pointer to gitattributes is probably the solution to this issue. Please allow me for some time to let this sink in.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de He is truly wise who gains wisdom from another's mishap.
On Wed, 5 May 2010 23:51:25 +0200 Wolfgang Denk wd@denx.de wrote:
Right. Well, Kim's pointer to gitattributes is probably the solution to this issue. Please allow me for some time to let this sink in.
ping - it's been two months.
Kim
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
Dear Kim Phillips,
In message 20100505160607.99edd83d.kim.phillips@freescale.com you wrote:
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.
This doesn't workl reliably. Too often companies insert their own version information there, which sometimes is completely unrelated to what we use.
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.
Ah! That's interesting. Another git feature I didn't know yet.
/me is reading the documentation.
Thanks a lot for this interesting tip!
Best regards,
Wolfgang Denk
On Wed, 5 May 2010 16:06:07 -0500 Kim Phillips kim.phillips@freescale.com wrote:
echo 'snapshot.commit' > .git/info/attributes
make that:
echo 'snapshot.commit export-subst' > .git/info/attributes
Kim
participants (6)
-
Kim Phillips -
Marek Vasut -
Peter Tyser -
Scott Wood -
Timur Tabi -
Wolfgang Denk