Revert #4306 - Stop marking go.mod and go.sum generated

[lildude]

As discussed in the original PR #4306, whilst the go.mod and go.sum files are indeed generated, it is widely expected for these to properly reviewed within a PR so shouldn't be suppressed in the diffs, as happens for generated files.

Of course this does mean we're back to them being incorrectly identified as another language and getting it's wonky syntax highlighting too. We can't associate these directly with Go as named files as they would then be treated as written in Go, which isn't the case, and as a result get wonky syntax highlighting then too.

Ideally having the files in Go syntax would be best, but failing that, the only other option I can think of it so add these files to Text so they don't get syntax highlighting, don't count towards the stats, and don't get suppressed in diffs either.

I'm open to suggestions on how to best address this part of things.

I've added a go.mod and go.sum file to the test fixtures to ensure they continue to be classified as text going forward. These two files are taken from https://github.com/golang/oauth2/ which is licensed under BSD-3-Clause:

• https://github.com/golang/oauth2/blob/5dab4167f31cbd76b407f1486c86b40748bc5073/go.mod
• https://github.com/golang/oauth2/blob/5dab4167f31cbd76b407f1486c86b40748bc5073/go.sum

Template removed as it's not relevant

[pchaigno]

If we add them as Text, won't we have to add corresponding sample files? The sample files may skew the Bayesian classifier...

[lildude]

If we add them as Text, won't we have to add corresponding sample files? The sample files may skew the Bayesian classifier...

Nope because we'd never get to the classifier as there'd only be one language associated with the filenames so Linguist will return that early.

[pchaigno]

But the sample files for a language are used by the Bayesian classifier for all extensions and filenames of that language. So adding these Go files may skew the results for say .ncl files.

[lildude]

But we don't need to add them 😉

[pchaigno]

Sure. Should we add a test to make sure they're not added? I'm worried someone might add them in the future ignoring the reason for their absence.

[lildude]

Should we add a test to make sure they're not added?

We could do, though other tests will pick up if they're added to Go (or elsewhere) whilst still being associated with "Text".

[pchaigno]

I probably wasn't very clear; I'm afraid someone could add samples of these files in samples/Text/.

[borgstrom]

Hi. 👋 Wanted to chime in here following #4357 (I still don't know how I missed this issue when I scanned the open PRs 🤦‍♂️)

Using the heuristics to classify go.mod as "text" seems fine to me. It could be satisfied with a pattern in the .mod section that matches the module location/path in the file. I don't have enough context with linguist to know if that addresses @pchaigno's concern or not.

I think that classifying go.sum is a little bit harder, and would opt for having it treated the same way that Gopkg.lock (or package-lock.json, requirements.txt, etc) are treated by leaving it as a "generated" file. All of these other lock files are also "widely expected for these to properly reviewed" but still require the viewer to click "load diff", so I think there's a pretty good case for it being the same in the go mod world.

[myitcv]

Any update on this, @lildude?

[lildude]

@myitcv I plan to finish this off today or tomorrow.

[lildude]

Test will start passing again once #4383 has been merged and I've pulled master into this branch.

[pchaigno]

LGTM!

[myitcv]

Quick question - when is this likely to go live on GitHub?

[lildude]

Quick question - when is this likely to go live on GitHub?

Hopefully sometime next week, depending on my workload.