On Fri, 30 Nov 2018, Alfred M. Szmidt wrote: > I disagree on that, you don't have to have any familiarity with that > at all to make useful contributions to glibc, nor should we make it
If you're trying to add a new (public) function - which is quite a common thing for new contributors to try to do, they have some problem for which adding a new function to glibc seems like a solution - then it's likely you'll run into various of those areas. > harder by requiring a complicated, hard to understand tool like git to > just be able to poke around in history. As with other things, people become more familiar with it over time. If you don't know C, you're probably not going to make many contributions to projects written in C. If you have basic C, you may be able to contribute in some areas but not others; more C expertise may allow contributing in more areas. Similarly, basic git allows basic investigations into history, and people can learn more advanced git over time. I think some knowledge of git is just as fundamental nowadays for much free software work as some knowledge of C, the Unix-like command line or a text editor. Projects can use different version control systems, just as they can use different languages. In both cases, a more obscure choice may reduce accessibility to developers. > understand history. And while git is prevailant, it should not be a > requirement that to one must be an expert in its use to be able to get > something half reasonable out of it. I'd go as far that how to do "half reasonable" does not require being an expert. "git blame" is more than half reasonable by itself, even without any knowledge of the other tools and the cases where you might want to use them or alternative options to git blame. > these queries is outside most peoples daily git usage. And this is I think "git blame" (and analogues such as "svn blame" or "cvs annotate") is pretty basic usage of git (or any other version control system). Fancier variants such as naming a revision with git blame (to see what changed before the last change to a given line), or using git log -L (to see changes that only deleted code, etc.), maybe less so, but people can learn those over time when they're looking at issues where those tools turn out to be helpful, just as they can learn more advanced usage of C over time. And of course people with difficulty debugging a problem can ask on #glibc or libc-help or libc-alpha (or any non-project-specific location) and get advice from people more experienced exploring glibc history with git, and likewise with any other project - we don't expect people to become expert at understanding and developing the code of a project in isolation, just reading instructions without experimenting and talking to other developers, the same applies to expertise in following the history. > ignoring non-developers ... something that has been the nicest way of > learning what is going on in a project is browsing the ChangeLog. I find "git log -p --stat" useful for that sort of thing (reading commit messages and diffs depending on what seems of interest). (Browsing list archives also shows things going on beyond just commits, if the project uses mailing lists.) > Personally I'd rather not spend time learning a dozen VCS and rather > spend it on doing actual work. Most of my usage of git is via vc-mode > in Emacs, is there some way of getting this information from there in > a VCS agnostic manner? I did not find anything like that, which is > the big benefit of ChangeLog-style files (be them autogenerated, or > manual). I've not tried using vc-mode for this, but Paul Smith already explained how to use it for a "git blame" operation <https://lists.gnu.org/archive/html/bug-standards/2018-02/msg00000.html>. -- Joseph S. Myers [email protected]
