Hacker News Reader

Comment by swang | Hacker News Reader

Uhm, yes I would rather not have it in my repo.

As to whether or not I want it tracked/versioned, that is completely outside the workflow for versioning in code in a repo. You can maintain a "version" of this separately ala Wikipedia's edit history, or even just have a hidden separate git repo for these things if you must use git. They already have this with gists.

With lint configs or npm configs you can argue that changes to those would affect code, which would require them to remain in sync. But what is the point of this new issue_template.md as part of the git repo? It's not as though there will be any significant time where a code change necessitates a change in how issue templates are made.

This feels like a bad hack. Like they saw CONTRIBUTING.md and thought, "well might as well just keep going" and added issue/pr templates.

View on HN

I totally get where you're coming from. An extra file in your repository is quite the burden. This template file is the straw that broke the camels back. It should be removed.

But why stop there? Let's also remove the README.md from the repo. It can also have it's own independent revision history. Maybe they should also add a feature for managing the LICENSE file for you.

/sarcasm

Except that CONTRIBUTING.md and README.md and LICENSE are all typical files found in a repo that are independent of GitHub. If I push this repo to bitbucket or gitlab, the same stuff is just as important. But `issue_template.md` and `pull_request_template.md` is only dependent on github and is clutter in the repo. Sure if gitlab or bitbucket have these features and use those names, cool it translates to those services too. But it doesn't matter to the code itself.

Ideally both of those files should be under a `templates` section in the repository settings tab.

We plan to support both .github and .gitlab in GitLab https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2864

Were any .md files really a thing before Github? Every pre-GH OSS project I can think of had a simple text file, or sometimes, HTML.

Besides what joshmanders said, I would argue a change in license is usually caused by a change in code and would also mark historically when a project went from X to Y. A README will probably also need to change with new code changes. As for having contributions file. I'm not really for that, but not against it either.

The problem isn't that it's just one file (actually 2 if you're counting pr templates), the problem is we're just going to continually get this pollution of the project because it'll become "acceptable." Slippery slope and what not.

I mean at this point why is the wiki in it's own space and not git versioned? (Put it in github-wiki folder!) Why have separate gh-pages as well? (Just stick them in github-web folder!). Just shovel everything into one git repo. Don't forget the .githubconfig file in case you want to programmatically config a repository instead of going into it's options menu. And on, and on, and on.

> I mean at this point why is the wiki in it's own space and not git versioned? (Put it in github-wiki folder!)

I understand your overall point, but as a slight aside the wiki is a git repo: https://help.github.com/articles/adding-and-editing-wiki-pag...

If gitlab stored its issues and wiki on a separate branch of the main git repo in some format I can still read when I decide that some other server (github, bitbucket or maybe just plain git), I would actually use those features. Right now they feel like completely unnecessary lock-in, so I’ll stick with Doxygen in-repo bugs/issues/todos and documentation.

Reply on news.ycombinator.com