remove unnecessary comments

[camio]

These comments add clutter in my opinion. If someone is editing this file,
they can search google to learn more information about pre-commit. We
don't, for example, link to the CMake homepage from our CMakeLists.txt.

Additionally, the other comments here are pieces of reference documentation
elsewhere.

[wusatosi]

Why are these comments considered unnecessary?

[camio]

Why are these comments considered unnecessary?

Please see updated PR text.

[wusatosi]

I don't think this is not useful... This makes clear that pre-commit does not dependent on system's clang-format.

[wusatosi]

I mean they can certainly search for it. But I don't think this is non-dependency is intuitive.

[wusatosi]

There are multiple CMake linters using different file names for their linting file. This is useful for alleviate confusion when someone brings in another CMake lint config.

[wusatosi]

You can see an instance of this happening here:
https://github.com/bemanproject/inplace_vector/pull/14/files#r1842893309

[wusatosi]

Why are these comments considered unnecessary?

Please see updated PR text.

See review comment.

Edit: I also think exemplar should be as descriptive as it can be. We create exemplar so people don't have to search stuff up. CMake is a common utility but pre-commit isn't. It doesn't hurt to be more descriptive, the comments are designed not to expire (e.g. they don't attach to a specific version of the dependency).

[steve-downey]

I agree that the comments are useful documentation, as finding the right cross references for these is extra work.

[camio]

Alright, I'm withdrawing this PR for now since there lacks consensus for it.

I maintain that the file is perfectly understandable without the comments since a) one can follow the link right below the comment to understand the semantics of what is being brought in, and b) googling for .pre-commit-config.yaml provides all the links necessary for understanding the utility of this file.

I also think exemplar should be as descriptive as it can be. We create exemplar so people don't have to search stuff up.

Exemplar's purpose is to exemplify best practices applied to a C++ repository, not to be a descriptive tutorial. Just as it is an anti-pattern to redundantly document the semantics of functions at their call sites, we should not document our tools where they are being used.