[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Kim Phillips]

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

>

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Wolfgang Denk]

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

-- 
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 at denx.de
The only thing necessary for the triumph of evil is for good  men  to
do nothing.                                            - Edmund Burke

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Kim Phillips]

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

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Wolfgang Denk]

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

-- 
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 at denx.de
Respect is a rational process
	-- McCoy, "The Galileo Seven", stardate 2822.3

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Marek Vasut]

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

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[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

-- 
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 at denx.de
"Love your country but never trust its government."
- from a hand-painted road sign in central Pennsylvania

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Timur Tabi]

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.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Wolfgang Denk]

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

-- 
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 at denx.de
I wish I had a bronze torc for every user who didn't read the manual.
                             - Terry Pratchett, _The Light Fantastic_

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Peter Tyser]

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

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Wolfgang Denk]

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

-- 
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 at denx.de
Speculation is always more interesting than facts.
                                    - Terry Pratchett, _Making_Money_

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Scott Wood]

On 05/05/2010 02:05 PM, Wolfgang Denk wrote:
> 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

Surely the extra quarter second is not too significant compared to the 
time it takes to formulate the query and examine the results.

> 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

It also requires that a cache be maintained just for this purpose.

> 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

$ 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

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Wolfgang Denk]

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.

> > 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
> 
> 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

-- 
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 at denx.de
Perl itself is  usually  pretty  good  about  telling  you  what  you
shouldn't do. :-)     - Larry Wall in <11091@jpl-devvax.JPL.NASA.GOV>

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Peter Tyser]

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>

> 3) it delivers only the lines I cactually search for, while "git log
> 4) I can use arbitrary grep options.  I am not aware of a git
> 5) 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

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Wolfgang Denk]

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

-- 
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 at denx.de
The human race is faced with a cruel choice: work  or  daytime  tele-
vision.

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Peter Tyser]

> > 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

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Wolfgang Denk]

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 at denx.de
He is truly wise who gains wisdom from another's mishap.

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Kim Phillips]

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

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Kim Phillips]

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

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Wolfgang Denk]

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

-- 
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 at denx.de
Mandrell: "You know what I think?"
Doctor:   "Ah, ah that's a catch question. With a brain your size you
          don't think, right?"
                - Dr. Who

[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Kim Phillips]

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