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 [email protected]
