People need to use a range of tools to find their way around a source tree with tens of thousands of files and work out which ones are relevant to edit to address their issue. For many things in glibc, people need to be familiar with many advanced GNU make features, with properties of the ELF object format and symbol aliases, with issues around ABI compatibility and symbol versioning, with namespace requirements of different standards, with peculiarities of various CPU architectures where those influence things in glibc.
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 harder by requiring a complicated, hard to understand tool like git to just be able to poke around in history. People with many years of hacking behind them have a hard time figuring out git, let alone how to do these magical incantations to 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 these queries is outside most peoples daily git usage. And this is ignoring non-developers ... something that has been the nicest way of learning what is going on in a project is browsing the ChangeLog. 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).
