From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Date: Wed, 05 May 2010 14:45:18 -0500 [thread overview]
Message-ID: <4BE1CACE.6040005@freescale.com> (raw)
In-Reply-To: <20100505190541.BFEFCB0FF8E@gemini.denx.de>
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
next prev parent reply other threads:[~2010-05-05 19:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-14 2:16 [U-Boot] [PATCH 2/2] remove main CHANGELOG file Kim Phillips
2010-05-04 21:41 ` Wolfgang Denk
2010-05-05 0:25 ` Kim Phillips
2010-05-05 6:54 ` Wolfgang Denk
2010-05-05 13:51 ` Marek Vasut
2010-05-05 14:17 ` Wolfgang Denk
2010-05-05 14:56 ` Timur Tabi
2010-05-05 15:07 ` Wolfgang Denk
2010-05-05 16:03 ` Peter Tyser
2010-05-05 19:05 ` Wolfgang Denk
2010-05-05 19:45 ` Scott Wood [this message]
2010-05-05 20:36 ` Wolfgang Denk
2010-05-05 20:37 ` Peter Tyser
2010-05-05 20:58 ` Wolfgang Denk
2010-05-05 21:43 ` Peter Tyser
2010-05-05 21:51 ` Wolfgang Denk
2010-07-16 18:44 ` Kim Phillips
2010-05-05 21:06 ` Kim Phillips
2010-05-05 21:07 ` Wolfgang Denk
2010-05-05 21:09 ` Kim Phillips
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE1CACE.6040005@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.