[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] Switch from CVS to GIT is done
- From: Jim Meyering <jim meyering net>
- To: Mark McLoughlin <markmc redhat com>
- Cc: libvir-list redhat com
- Subject: Re: [libvirt] Switch from CVS to GIT is done
- Date: Mon, 06 Jul 2009 17:48:13 +0200
Mark McLoughlin wrote:
>> What do you think of coreutils' logs?
>> It's generated and still ChangeLog-conforming, yet with an added
>> one-line summary and sometimes (for larger changes) more prose:
>>
>> http://meyering.net/code/tmp/coreutils-ChangeLog
>
> Looking at the git commits e.g.
>
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=24c727d3
>
> it doesn't duplicate date/author and has a good first line summary, so
> it's pretty good.
>
> The one question I'd have is whether listing of per-file changes has any
> value. IMHO, it tends to restrict the explanation people give about
> about their commits. Looking at projects that don't do this, I think you
> tend to get much more background on why the change is being made, not
> just what changed.
IMHO it's more about habit than which format you use.
I find the ChangeLog discipline is worthwhile, because
it forces me to go back through the patch and write something
for each changed file. Besides, if you use a tool like vc-chlog
to write the template for you (http://www.gnu.org/software/vc-dwim/)
it removes the pain of enumerating affected files and function names.
Also, the companion, vc-dwim, has saved me regularly by telling me
when a file I'm about to commit has unsaved changes -- it detects
editor temporary files. It's caught emacs buffers with changes that
weren't saved at least 2 or 3 times in the last week or so.
coreutils is in a mode for which one-liners are often enough,
but I do admit that the log messages are sometimes too light on prose.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]