Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing new tools, forums, and features

github.com

Post reply on HN
Print view View original

171–180 of 282 posts

Re: Announcing new tools, forums, and features

#171

Post by postit »

dr_win wrote: post #148
rogerbinns wrote: post #44

Earlier quoted context omitted.

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 collabo…

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

Just no.

Re: Announcing new tools, forums, and features

#172

Post by welder »

bsimpson wrote: post #9

I'll be curious to see if they've made API granularity more sane. We haven't been able to use any third party tools because our security people don't feel great about giving third parties write access to everything (including our source) for tools that don't need it. In the past, GitHub hasn't differentiated write access to issues (which many tools need) and write access to the source itself (which basically nothing…

WakaTime has been bitten by this lack of granularity too... it hurts integration usage when we ask for code access when we only need commit log messages.

Re: Announcing new tools, forums, and features

#173

Post by makecheck »

I’m not sure if the name “project” is a good choice here.

For one, GitHub still has some pages that refer to the idea of creating projects on GitHub, except those aren’t referring to these new kinds of “projects” (they actually are referring to new repositories or new accounts or something).

And, there are literally over a million repositories that have the name Project or Project somewhere in their name[1] so you can now create projects within things that are already called Projects (except the “projects” act more like issues, or tasks, or something).

Naming is important, there’s a reason why engineers devote so much time to it.

[1] https://github.com/search?p=1&q=project&type=Repositories&ut...

Re: Announcing new tools, forums, and features

#174

Post by rsanheim »

toddsiegel wrote: post #87
jglovier wrote: post #32

Earlier quoted context omitted.

Great idea. Thanks!

While I have your attention. A few thoughts on code reviews. It's be nice if 1) approvals somehow show up on the pull requests index page, 2) create a notification within GH, 3) send an email. Right now you have to go to the PR page itself to see approvals. Edit: I saw an approval email notification on one PR, but not another. Thanks!

All reviews definitely generate notifications.

We definitely want to get some way to surface reviews better across all PR's and/or projects. I've been bothered by that myself while we were building this. :)

Re: Announcing new tools, forums, and features

#175

Post by yosyp »

dr_win wrote: post #148
rogerbinns wrote: post #44

Earlier quoted context omitted.

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 collabo…

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

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.

Re: Announcing new tools, forums, and features

#176

Post by majewsky »

BinaryIdiot wrote: post #13

The review stuff is semi similar to what I requested GitLab do and I'm surprised it's taken so long for anyone to really do it. It's a great workflow. I'm still not convinced about keeping all of your project's management in the version control system (I mean I prefer issues in there but the rest seems...wrong to me for whatever biased reason I have). Overall looks good! When does Enterprise get these features? :)

The review stuff actually reminded me of http://review.ninja, which has existed for at least 1.5 years at this point.

Re: Announcing new tools, forums, and features

#177

Post by majewsky »

misiti3780 wrote: post #162
toddsiegel wrote: post #30

If anyone from Github reads this, a) this looks great, b) add project templates please, so we don't have to recreate the same columns every time. Thanks. <3

d) create issue templates also, i have to currently cut and paste the same markdown into every issue e) create user-level permissions - i work on a team where everyone would use this, but currently not everyone can have access to the code base so we have to say in trello until you can allow me the ability to turn off code access to "non-engineers"

Issue templates have been a thing for some months now. https://help.github.com/articles/creating-an-issue-template-...

Re: Announcing new tools, forums, and features

#178

Post by Whitestrake »

elliotec wrote: post #83
chipgap98 wrote: post #76

Earlier quoted context omitted.

Price isn't a product differentiator?

The feature isn't a product differentiator.

If I had unlimited money, I could hire an army of coders to write me a git platform with all the features I want, and host it on all the servers, everywhere. It's simply not feasible to talk about product features in a vacuum without considering the costs.

Price is a feature.

Re: Announcing new tools, forums, and features

#179

Post by jacques_chester »

dr_win wrote: post #148
rogerbinns wrote: post #44

Earlier quoted context omitted.

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 collabo…

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

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.

Re: Announcing new tools, forums, and features

#180

Post by the_duke »

bentlegen wrote: post #80
markdog12 wrote: post #61

Earlier quoted context omitted.

> I don't really quite understand all the love of GitLab - Open Source - Free private repos - Free self-host (edit to add "Free") - Everything in one spot (repos, ci, review, coding environment, etc...)

> Open source* The Enterprise edition features[1] are closed source, and these aren't strictly "enterprise-y" features like SAML authentication. It includes plenty of "basic" workflow features found on GitHub: - Rebase merge requests before merge - Use fast-forward merges when possible - Create templates for issues and merge requests - Display merge request status for builds on Jenkins CI [1] https://about.gitlab.com…

So what, some advanced features are enterprise only...

They have to make money after all.

The 'basic' product (which is far more than basic) is open source though, which incredible.

Post reply on HN