On Tue, 1 Aug 2017, Alfred M. Szmidt wrote: > $ 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". > everyone. People who keep suggesting git as a solution miss the point The ChangeLog works only if they have questions at an extremely specific level (wanting human-readable descriptions of changes split up into how individual named entities are changed, but not the associated diffs or source tree versions, relating to changes that can readily be described at that level) > of being able to extract this information in a archivable format. You could have a -with-history.tar.xz tarball if desired, including the git history (or simply ship the log of *logical-level* commit messages in tarballs, without trying to decompose descriptions of complicated global changes into per-named-entity fragments). 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. I fully encourage the development of tools for export of such rich structured data for free software projects, in a form that can be imported into another free software development site, as well as the development of software for free software hosting sites that supports such import and export of structured data. (Cf. ESR's past blog postings about the problems with software forges not supporting such export.) I do not think requiring use of a particular text format for a very limited subset of the history information is a useful part of ensuring the development history of free software projects remains readily accessible in future. -- Joseph S. Myers jos...@codesourcery.com