On Sun, Apr 17, 2011 at 01:29:27PM +0100, Thomas Adam wrote:
> Hi all,
>
> I said I would try and outline where I think we should be in terms of moving
> to git. I have to say that I am surprised at just how sudden such a switch
> has taken place; in the past I had asked Jason and Dominik off-list what
> would be involved, and whether it was a good idea. Reaction from both of
> them was largely positive, and I think for different reasons. As I see it:
I forgot to mention the ChangeLog.
ChangeLog
=========
Because commits are changeset-based, it's very easy to see in a given commit
the files which touched it. This almost goes someway to making a overall
ChangeLog file moot -- I can see/know why projects using other revision
control systems use them, but they're perhaps superfluous with git.
In order to understand why, I suppose it's important to understand the
anatomy of a commit. Here's a typical one from me (again from
ta/titleformat):
commit 8d5837d7488fcdf7ca7ee7aceb6a1ca3d7777799
Author: tadam <tadam>
Date: Fri Oct 15 05:02:19 2010 +0000
FvwmIconMan Transient mode to accept explicit module alias.
When running FvwmIconMan in transient mode, allow for an explicit module
alias to be used, rather than defaulting to "FvwmIconMan". This brings
FvwmIconMan in-line with other modules which provide similar
functionality.
The very first line in the commit message is called a "shortlog", it's a
single-sentence describing what the commit is about. Then there's a blank
line followed by the body of the commit message, which describes in more
detail the change.
I can get an overview of all shortlogs on a branch by running the "git
shortlog" command. I can also see from this commit what files were changed
by it:
[n6tadam@debian][fvwm][ta/titleformat]% git show 8d5837d7 --stat --oneline
8d5837d FvwmIconMan Transient mode to accept explicit module alias.
NEWS | 2 ++
modules/ChangeLog | 9 +++++++++
modules/FvwmIconMan/FvwmIconMan.c | 8 +++++++-
3 files changed, 18 insertions(+), 1 deletions(-)
Here, "--oneline" just shows the shortlog from the commit in question,
without showing the full message.
So in this way, it's still possible to generate a ChangeLog *after* the
fact. With git tags (which we'd be using anyway on master, when "next" is
merged. As an example of this:
[n6tadam@debian][fvwm][ta/titleformat][128]% git shortlog
version-2_5_29..version-2_5_30
dane (1):
remove bad error message
tadam (7):
Version bump CVS version to 2.5.30
Don't allow incremental matching of C_ALL with "PrintInfo Bindings".
Fudge PNG macro detection based on version of libpng.
NEWS/Changelog for previous commit.
Tidy-up todo-3.0
Cosmetic clean up for NEWS file.
Update key files for FVWM 2.5.30 release.
I think saying goodbye to a formal ChangeLog, given CVS made the above
annoying/impossible would be useful, it's meta information we don't need
given Git tracks this for us.
-- Thomas Adam
--
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.
