3 ms·
Something only belongs in the same branch as the code if it should be forever tied to the same version as the other files in that branch. Suppose I check out a
by makecheck 11y ago
Something only belongs in the same branch as the code if it should be forever tied to the same version as the other files in that branch.
Suppose I check out a project using a version from a year ago. Project maintainers would certainly not expect me to use last year’s issue template, last year’s preferred pull request layout and last year’s rules for contributing! That is why shoving things into the "git" repository is a hack.
Having this stuff under some revision control is useful but it could be a separate, parallel repository. Frankly, I think everything for project management should be in one repository, and everything for code and documentation should be in another, and GitHub should be able to use files from both to present a project site.
- BHSPitMonkey 11y agoGitHub is always going to use the issue template that's on master, not the template from whichever version you happen to have checked out on your machine.
- joshmanders 11y agoCurrent file on master to boot. But what makecheck is saying is that only what's in current master matters, not what's in `feature/something-here` or in a commit tree from last year. So shoving it in the repo isn't really a good solution.
- BHSPitMonkey 11y agoIt's the same way with README, CONTRIBUTING, LICENSE, Makefile, package.json, and anything else.
- joshmanders 11y agoNo it's not. I can use the README outside of github as a guide on how to do things with the code. Contributing can define a style guide so we're all on the same page code wise. LICENSE for distribution, Makefile, package.json both are required for the code to work correctly... issue_template.md is only useful in a repo on github.
- steveklabnik 11y agoWith Rust, we already had a mini-template inside of our CONTRIBUTING.md. Doesn't seem very different to me.
- dwightgunning 11y agoHaving the templates in the repo at least gives you a degree of portability. I'm guessing there isn't an "export issues" feature so the above point is moot. I favour the portability.
- jrochkind1 11y agoSure you can export issues from Github, easily. https://api.github.com/repos/rails/rails/issues https://api.github.com/repos/rails/rails/issues
- JBiserkov 11y agoLast time I checked the Wiki was a separate, parallel repository, so a precedent exists. I'm not sure where it fits in your classification (code/documentation or project management).