4 ms·

This has been why we don't use github's issues, wikis, and why we won't use their projects. For example if the overall product has a web site repo, server repo

This has been why we don't use github's issues, wikis, and why we won't use their projects. For example if the overall product has a web site repo, server repo, iOS repo and an Android repo then they need to be used as a coherent whole. An issue might be reported against iOS but the cause is in the server, so the ticket would need to be moved. Rinse and repeat for all the other interactions of piece, and that collaborators often don't know (and shouldn't need to) precisely what issues, wikis etc correspond to which repo. The now defunct Google Code had a very good solution for this. You could create additional "sub" repositories alongside the "main" one. Github already does that for the wiki, but doesn't generalise it to allowing additional ones. I'm somewhat convinced this is because github has the whole "charge by the repository" model, which is at odds for being useful for projects that require multiple git level repos.

toupeira 10y ago
They recently added a per-user pricing model, so maybe they would be open to suggestions.
- rogerbinns 10y ago
  It would require fairly extensive changes on how they do things under the hood. Google used suffixes - eg you checked out the wiki as github.com/org/projectX.wiki and could create a git repo like github.com/org/projectX.android
dr_win 10y ago
I would put all projects under one repo as orphan branches. With some branch-naming conventions you can easily separate those.
- postit 10y ago
  Just no.
- yosyp 10y ago
  Imagine you just hired a new web developer, and added him to this repo. His first local repo clone will include 3 entire projects for iOS, Android, and backend server, that he has no use for, or should even have permissions to access in the first place. This sounds like a security nightmare, that also significantly impacts local update times and makes for a huge repo.
  - vernon99 10y ago
    So companies like Fb (with their gazillions of files) can afford a single repo and you hiring a new developer cannot?
- jacques_chester 10y ago
  I loathe orphan branches with an intensity that could produce a nation of orphaned children. My view is: unless you have an inescapable security, physical or performance reason not to have a single repo, have a single repo. Directories are for managing directories. Version branches are for managing versions. They are not the same thing.

toupeira 10y ago

They recently added a per-user pricing model, so maybe they would be open to suggestions.

rogerbinns 10y ago
It would require fairly extensive changes on how they do things under the hood. Google used suffixes - eg you checked out the wiki as github.com/org/projectX.wiki and could create a git repo like github.com/org/projectX.android

dr_win 10y ago

I would put all projects under one repo as orphan branches. With some branch-naming conventions you can easily separate those.

postit 10y ago
Just no.
yosyp 10y ago
Imagine you just hired a new web developer, and added him to this repo. His first local repo clone will include 3 entire projects for iOS, Android, and backend server, that he has no use for, or should even have permissions to access in the first place. This sounds like a security nightmare, that also significantly impacts local update times and makes for a huge repo.
- vernon99 10y ago
  So companies like Fb (with their gazillions of files) can afford a single repo and you hiring a new developer cannot?
jacques_chester 10y ago
I loathe orphan branches with an intensity that could produce a nation of orphaned children. My view is: unless you have an inescapable security, physical or performance reason not to have a single repo, have a single repo. Directories are for managing directories. Version branches are for managing versions. They are not the same thing.