Re: Status update - version 5.2.2, cvs->git conversion, plans

[Tait <gnu...@t4...>]

> >> 1) Ask the people submitting patches, via their git tools to include the
> >> file change info in their log messages
> > 
> > Please, let's not do that. Version control already has this information,
> > and asking humans to replicate it is both effortfull and error-prone.
> > Does 'git log --stat' give you what you want?
> 
> It doesn't.  Stat tells you what files have changed, but it doesn't 
> indicate why.  As an example, here is what is done for Octave:
> 
> http://hg.savannah.gnu.org/hgweb/octave/rev/f8c263f961c1
> 
> ...

I feel like the change log duplicates the history in git itself,
as Dima has argued. One thing to keep in mind is that git
allows, even encourages, smaller commits. Things that might have
been a single commit before would be treated as a branch (called
"feature-branch") in git. Because a whole series of commits can
be pushed at once, there's no reason to combine connected-but-
discrete pieces into one commit. Take the Octave commit as an
example:

*) Create shared_ptr branch
*) commit 1 message: "Remove base_graphics_object:count"
   followed by an explanation of why it's being removed, and
   any concerns or considerations regarding its removal
*) Commit 2: Use default constructors/destructors for <____>
   Again, the latter part of the commit message should cover
   the "why?", because it's not clear why the defaults weren't
   being used before.
*) Commit 3: Change rep to shared_ptr
   A plain pointer is problematic because ... etc.
   The shared_ptr conversion requires all direct assignments
   to rep be replaced with ... etc.
*) merge shared_ptr to master
*) [optional] delete shared_ptr branch

Then this 3-commit branch gets pushed and merged back (or
fast-forwarded) into master all at once. If some part of this
proves later to introduce a regression, having smaller commits
makes it easier to bisect and identify precisely the problem.
And I can't imagine what a change log would add above and beyond
what's there already.

As to the proofreading, I find I naturally do this in between my
local commits and pushing them to a remote. I always use a
combination of diffstat/log/show to review what I'm about to
push -- to make sure I'm pushing what I think, and as a last
chance to catch bad formatting or other errors. Once pushed, it
can't be taken back or rewritten, so a little extra care helps.