Hacker News Reader

Comment by sgarrity | Hacker News Reader

Some nice improvements here. It appears, though, that Projects suffer from the same problem we've had with Issues: they are limited to one repo.

I know there are some tools to manage Issues across repos, but for the most part, the tools seem to assume you work on only one repo, or that milestones only affect a single repo.

I would love to see projects/milestones become more capable when dealing with cross-repo issues.

View on HN

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.

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

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

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

Just no.

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.

So companies like Fb (with their gazillions of files) can afford a single repo and you hiring a new developer cannot?

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.

Take a look at ZenHub [1] - it lets you stay inside GitHub, but adds much more full-featured project management capabilities including multi-repo boards and advanced reporting features like estimates, issue hierarchy (epics), personal to-dos, burndown and velocity charts, etc.

[1] https://www.zenhub.com

Phabricator has the right approach here.

Issues and projects are global and not bound to a single repository. In my experience, this is the only approach that works in a company. JIRA does the same thing.

It's the closest to a fully open source Atlassian suite that you get. Phabricator has code review, repository hosting, project management and even a CI tool.

I've seen a few projects use Phabricator, but I can't seem to understand how to use it.

Github's issues, despite it's flaws, is easy enough that non-programmers can use it. Phabricator is complicated enough that it's actually caused me to not report a bug at one point.

At Goldbely, our solution has been to have a single GitHub repo that's just for issues and use tags to highlight the actual code repos involved.

Works pretty well, if a little awkward at first.

We do this as well at Purple [0]. It does make issue referencing in commit messages a bit unwieldy; you have to include the full path to the issue (e.g., org-name/repo-name#34).

[0] - http://purpleapp.com

Thanks for providing the feedback here - I've passed it along to the Engineering team building out Projects.

I'm curious as to whether you are dogfooding Projects, especially when feature work spans multiple repos. If so a "how Github uses Projects" tutorial may be worth considering.

Indeed, many teams are - the original iteration of Projects was released to staff a few months ago (as is common with many of our product releases), so we're continuing to learn how teams are using it most effectively. Yesterday's release to the public will help with that effort too.

I personally use it on my team at the moment - it's been pretty useful and we've passed along frequent feedback to the platform team responsible for it.

This. There are fewer and fewer places for single repository applications in this day and age: We break out a repo for everything to our DDL / Stored procedures and of course our API vs. Front-end code.

It sort of boggles the mind, really - and makes me feel like they did not really take the community's desires seriously.

Yup! Using Projects will force us to maintain multiple projects for one single "real" project, as our code is split across multiple repositories. (Web app, desktop client, infrastructure, company issues, etc)

I suspect it's still a lot better than the alternative but not having org-wide Projects is a little sad.

For what it's worth, I've had success browsing issues accross repos using the https://github.com/issues page. E.g. to view all issues that are in both redux and react-redux:

https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Are...

Codetree [1] addresses the multi-repo issues problem you mention, we roll up as many repos as you want under one 'project' which you can view in either table or kanban board style.

We also add a host of project management functionality on top of GitHub issues like advanced filtering/sorting, dependency tracking, and the ability to setup your own dev/release workflow.

[1] https://codetree.com

Reply on news.ycombinator.com