Re: Circumstances in which ChangeLog format is no longer useful

[Joseph Myers]

On Fri, 4 Aug 2017, Alfred M. Szmidt wrote:

>    No, we should expect people to learn whatever tools are appropriate for 
>    working on the projects they are developing.  It's not the place of the 
>    GNU Coding Standards to tell people how to extract particular information 
>    from version control history.  And I'd expect most git guides to 
>    concentrate on things such as git bisect, because I'd expect "find the 
>    revision that introduced a bug" to be a more common issue than "find all 
>    changes affecting a symbol called X, across all source files".
> 
> We cannot expect people to learn a multitude of different tools, or
> tools that have vanished from history.  The above commands might not

I don't think learning the tools used by a project for version control is 
significantly different from needing to know the languages it's written 
in, or used to be written in, or the tools used in its build process, or 
formerly so used.  We might recommend a handful of commonly used version 
control systems, just like a few languages are recommended.  And version 
control history can be converted automatically much better than e.g. 
source languages.

> When a git repo grows extraordinarily large the recommended action is
> to nuke it, and start over.  This looses _all_ history, meta-data, and

That is very definitely not recommended and we should not point to any 
such bad recommendations.  As I've said, it would be reasonable to put a 
requirement to convert history if changing VCS and using version control 
log messages (describing changes logically at the changeset level instead 
of split by files and entities therein) instead of ChangeLog format.

The point where conversions can be tricky and lose information is very 
specifically converting from a non-changeset based system such as CVS to a 
changeset-based system, where heuristics need to be used to group changes 
to different files that should go in a single commit.  Once in a 
changeset-based system, conversions are essentially lossless, with only 
odd details such as subsecond timestamps being potentially lost if one 
system supports them and other doesn't, not the basic structure into 
commits and log messages and authors thereof.

As far as I know, all distributed VCSes are also changeset-based, but we 
could put being changeset-based in the requirements for using version 
control log messages at changeset level in place of ChangeLog format.

-- 
Joseph S. Myers
address@hidden