Re: Commit practices

[Karl Fogel]

Richard Stallman <address@hidden> writes:
> The reason I have asked people not to commit multiple files
> is that they bloat the log entries of each file, making them
> essentially unusable.
>
>     I did it this way for a reason.  Someday we are going to want to
>     migrate the CVS tree to a VCS that has real changesets.  We're almost
>     certainly going to do it with a tool functionally like cvs2svn that
>     tries to reconstruct commit groups using date, the content of the
>     comments, and possibly this Commit-ID thing I see in the CVS logs. It
>     will be helpful, when we do that, if there as many similarities across
>     related commits as possible for the migration tool to grab onto.
>
> In effect, the suggestion here is that we abandon the idea
> of useful readable info associated by the VCS with each file.
>
> That would mean that the ChangeLog file is the only place
> for such info.
>
> I won't say "absolutely not".

Grouping each logical change together in one commit (even when the
change involves multiple files) allows tools like cvs2cl to do their
job (see http://www.red-bean.com/cvs2cl for more).  Thus, the info
recorded by the VCS *would* still be useful -- no need to abandon that
idea.  By the way, cvs2svn uses essentially the same algorithm.

So, the ChangeLog would not be the only place for this info.

Also:

All the CVS documentation I've seen specifically recommends grouping
each logically unified change together in one commit.  That is also
the way I have always used CVS, and the way CVS maintainers use CVS.
I realize this sounds like "argument from authority", but given our
finite resources, the time-tested experience of others may be worth
taking into account.

-Karl