bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Circumstances in which ChangeLog format is no longer useful


From: Alfred M. Szmidt
Subject: Re: Circumstances in which ChangeLog format is no longer useful
Date: Fri, 04 Aug 2017 10:48:58 -0400

   >    $ git log --grep=NFPREG
   >    $ git log -E --grep='N(FP|G|VR)?REG'
   >    $ git log --grep=NFPREF -p
   >    $ git log --grep=sysdeps/arm/sys/ucontext.h [-p]
   >    $ git log -G'fpregs' -p
   > 
   > And what about non-git?  Should we list every magical invokation for
   > every VCS that is in use?  An extracted ChangeLog works for anyone and

   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
even be available in other DVCSs that fall under the critera you
listed, nor are they available under normal usage in for example
Emacs.  I know how to use Emacs, I have no intention of learning to
use at least 5 different version control systems, and then expecting
everyone to do so is something that is infact useless and a waste of
time.

The ChangeLog file is both version control agnostic, and a permanent.
When a git repo grows extraordinarily large the recommended action is
to nuke it, and start over.  This looses _all_ history, meta-data, and
all.  At some point in the future we will use some other VCS, then we
will need this data again.  None of the above commands help in
preserving what is going on over the course of many VCS changes.

Taking Emacs or glibc, it is trivial to go back several decades of
changes -- across at least three version control systems that have
been used in some form where data has been lost (and lots of time has
been spent on recreating it!)

   For people to follow development history properly requires the
   actual VCS history, not just logs (any forms of logs). And the
   mailing list archives, and the issue tracker, and quite likely
   other tools such as patch review systems.

As someone who does follow developement, I can prove this as totally
false.  I don't use mailing list archives, nor VCS history to see what
is going on, I use the ChangeLog.  I'm also sure there are far more
people that do that, so as to what people actually do we better leave
as speculation since we cannot know how they do it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]