Github success was about making code repositories pretty and social. But this is no longer enough to keep evolving as a company of their size. Yet the internal product DNA still revolves around repos, so as a result, issues, wikis and now Projects (!) live under a single repository.
This is backward.
A project is a way to group resources to achieve a predefined goal. Those resources include multiple people, multiple issues and multiple repositories. Sticking a project under a repository makes no sense.
In fact, a code repository in most organizations is a fairly small and an insignificant asset, just another way to organize code, i.e. function -> module -> directory -> repository, etc. It's quite awkward to think of what your company is doing in terms of repositories, so anything Github adds to repos feels out of place by default.
Another example of repository-centric thinking is the homepage of https://github.com itself when a user is logged in. It's the most important page of all, yet nothing on it has any relevance to me: just a list of people I like starring random repos. Same thing for the organization home page, just a list of repos, again.
The Project idea is great. It had the potential to solve all of these issues by giving me a tool to organize digital assets in a way that's important to me. But sticking it under a repository killed it.
[EDIT] It's easy to be me and be posting a comment like this, telling successful people what to do. But it's enormously hard to have a large team of PMs, developers and designers, all of whom are smart and ambitious individuals, to actually do something that falls outside of the settled way of doing things. Kudos to Github founders and employees for getting it this far and congratulations on dealing with big company problems ;)
We at GitLab are trying to keep it simple by having only one repository, one wiki, one issue tracker, one CD pipeline, and one set of milestones per project. Projects always below to a group. We aggregate on the group level, for example issues https://gitlab.com/groups/gitlab-org/issues, merge requests https://gitlab.com/groups/gitlab-org/merge_requests and milestones https://docs.gitlab.com/ce/workflow/milestones.html#groups-a...
There are several things we're still considering to solve this problem better, comments are very welcome:
1. Multi project pipelines https://gitlab.com/gitlab-org/gitlab-ce/issues/17069
2. Group level issue boards https://gitlab.com/gitlab-org/gitlab-ee/issues/928
3. Nested groups https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
GitLab staff are "on point" by commenting on anything relevant to their industry (code creation/management) where their target customers are (HN).
To other founders, this is what good marketing looks like.
Hope you can keep it up! :)
But the facts are such:
1) GitLab is a YCombinator incubated company.
2) GitLab and GitHub are direct competitors
3) It's almost always relevant to the discussion, in this case; "How could it be done differently, how /has/ it been done differently"
In this case I think it's fair to bring up the direct comparison of github and gitlab. The only thing I would say could improve the situation was having github representation on here too.
If this is how all marketing would always look like, I wouldn't hate it like I now do.
Of course it fits with the model of an open source company, but it still makes me skeptical intuitively. (I say this less as a criticism and more as feedback on how one random HN user perceives their presence.)
I release computer games, which are developed largely in secret and when they hit the market after 4-7 years people find all kinds of warts and issues that we never even thought of.
GitLab seems to be of the idea, "ask people what they need, make small incremental movements into making that happen and release those increments often so that people don't get jarred by changes"
I can support that, and I don't think it bears negatively on their integrity.
What bugs me a bit is mostly the constant presence on the Hacker News forum, with this somewhat aimlessly customer-pleasing tone: "What can we do better? How can we improve your experience?" etc.
It seems like a premeditated PR/marketing strategy, which might be working well, but it's still off-putting to me.
Have we reached a point where all pleasing tones are considered marketing and PR? That we distrust people for acting earnestly?
It's in gitlabs best interests to be a superior product, right now they're an underdog, and their ubiquity on hackernews is not a coincidence, they're a YCombinator backed start-up.
Talking directly to people tends to focus the conversation too much without allowing outside perspective, you might want all of gitlab to be focused on CI, but I may think a casual CI integration would be more reasonable and likely a good solution is a middle ground- also, who do you ask? people rarely talk about their VCS unless it's relevant to discussion.
Asking the community for opinions is a great thing to do - you might get some good suggestions and the community then feel valued. That doesn't mean you need to do exactly what the community tells you, but taking it into account in the design process may help build something that the community actually wants to use.
however, unless i'm missing something, a "project" in bitbucket is basically just a folder to group your repositories in. there's no real features associated with it. A github project is project management tools based on a repository.
If GitHub had called their feature something else, (for example, call it "the board") and nobody would be expecting it to be anything other than per-repo.
In the future you will see us adding more capabilities to projects, such as permission management  or settings on a project level, which already exist in Bitbucket Server.
E.g. I come at things from the intersection of (embedded) product line engineering and continuous integration, which leads me towards a different place than somebody coming at things from (e.g.) consulting or web services ... but it is difficult to have a meaningful discussion about the pros & cons of each approach without the language / terminology that we need.
I hope Github rethinks their design and places Projects under user and organization profiles, rather than repos. It's a very useful feature that's sadly trapped in a single repo.
Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?
I think this depends on your job function. At Codetree we have a bunch of customers who need to see a project that spans multiple GitHub repos. The person who needs this view is the person responsible for delivery - usually a project manager, a product manager, or a dev manager.
A common example is a project that spans an API repo, a front end repo, and a mobile repo. If you're responsible for delivery, you want to be able to answer questions like "How much work is left to deliver the FooBar feature", or "Show me all the tickets assigned to Joe". To answer these, you must see issues from multiple repos rolled up into a single view.
Then, when you change the API, you don't have to create 3 pull requests across 3 repos, just ONE pull request and teams can review all the changes together.
And your problem of searching for issues assigned to one person across multiple repos is not a problem any more.
There are already many good examples of managing multiple modules inside one repo:
Another one is where we have forks of libraries with minor patches to suit our needs.
Spinnaker is comprised of a bunch of quasi-independent microservices, designed to work together. I don't think it would necessarily make sense to have them all in the same repo, when they could be swapped out or even used separately in another project.
But yes, someone, please make something that kills JIRA as soon as possible.
For example, if they allowed repo projects to reference issues in other repos, that would you get you 99% of the way there. You could start a single meta-repository that referenced as many repo-specific issues as you cared to consider.
1. projects. replaces trello, waffle.io, zenhub and many other similar services.
2. code reviews allow approval/request changes as sunny's screenshot shows
3. reviews can be made mandatory.
4. github platform integrations is getting a roadmap
5. a graphql api to query their database
6. enforce 2fa in organizations (much love for this one)
7. summarized timeline for your contibutions
Just a few days back, at the GitLab release, I'd noticed a lot of complains about gitlab releasing useful and impactful features and github being slow on releases. Moreover, now with a public roadmap (even if it is just for platforms), it is a great start.
I'm really liking this change in pace.
mods: Can we make this the canonical discussion for this topic? Otherwise, a lot of branching will happen
- Open Source
- Free private repos
- Free self-host (edit to add "Free")
- Everything in one spot (repos, ci, review, coding environment, etc...)
The Enterprise edition features 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
It has many enterprise features including code ownership, issue templates, and a Gerrit like, sane code review workflow. You can fully integrate it with your CI tool and it even displays coverage results inline and such.
Ask me anything about it :) I'm not affiliated with it but am an experienced user.
On top of that it was really painless to install locally. I had it setup in under an hour, and that included my first time ever setting up my webserver with php, and first time configuring a mysql instance.
Based on my experience, Phabricator has some quirks but is quite solid, and the well-designed command line arc workflow would please folks who refuse to open a Web browser.
I wonder how it compares to GitLab. Is it possible to set up protected branches, where I can say, only users X and Y are allowed to push to the master branch? Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature? Because currently in GitLab the author does get a notification email for every line comment I make, which is also not really the perfect way of doing it.
I already know that Phabricator squashes the changes into one commit, I think I can live with that. (because it promotes small code reviews) Does Phabricator have any problems with git rebase, where I'm refreshing a feature branch with the most recent master state? What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?
Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello. Can it be used by non-developers without giving them access to the code?
Looking forward to test Phabricator tomorrow.
Yes. I recommend (and my employer uses) a Herald rule that admits pushes to master only if the changes are in an approved Diff (unit of code review). This way you get an enforced 2-man rule, but anyone besides the author can approve the change.
This is currently impossible with Gitlab AFAIK, and is the main reason I won't use it.
You can also configure Herald rules to add blocking reviewers to other people's Diffs based on arbitrary criteria (i.e. touches X file and it's a Tuesday). A Diff cannot be considered approved until all blocking reviewers have signed off.
Reviewers can also be groups, so you could say, for example, changes that touch Y file must be reviewed by Security, but any member of Security can sign off.
>Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature?
Yes, everything you do on a Diff is batched and happens all at once when you click "Submit" at the bottom. Inline comments, the free-form text box, and the action all come as one email.
> What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?
A Diff is really meant to be an individual's small, well-defined contribution. Multiple people submitting code to a one diff can get messy. This would be better modeled as many diffs.
You are allowed to land diffs against branches other than Master, however this gets messy. It is not a first-class use case. My employer does not collaborate on feature branches; instead we land half-finished features into master (and production) disabled by feature flags.
It is NOT a merge/pull-request workflow. It treats Git more like Subversion; Phabricator is a very sophisticated alternative to emailing patches around before SVN committing them (basically the equivalent of landing).
>Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello.
Issue tracking is totally solid, very configurable. Project workboards consist of tasks/issues, which are much more expensive to create than Trello cards: you fill out a pagelong form, pick type, severity, owning team, title, description, etc. vs just free-forming a title. However, you can drag tasks around the workboard just like Trello and it looks pretty similar.
>Can it be used by non-developers without giving them access to the code?
Yes. Permissions (and approval flows, and notification rules) are very configurable. Phabricator is well suited to a large organization with rules, but this suitability doesn't carry too much overheard.
I don't think you could collaborate on issues with customers. Nontechnical people in your company, though, totally - we do that.
Due to popular demand, they are adding some tools to allow merge/PR workflow. That being said, it was not stable last time I checked (~6 mo. ago), and it will probably take a while, if ever, for it to be as good as what's already there for Differential (the current code-review/landing system).
That being said, their existing tools are really good, and the fact that you are not married to a single VCS is really nice. You can have some legacy SVN repositories and be fine, and use the exact same interface for code-review and landing as in your shiny new git repositories. Prefer hg to git? No problem. Have some complicated gitolite setup you don't want to bother migrating? Phabricator works fine even when not hosting the repository.
I want to echo here what I said in https://news.ycombinator.com/item?id=12501271 "If there are features that people think that should belong in the open source edition we're all ears. We've done so before https://news.ycombinator.com/item?id=10931347 A feature comparison between CE and EE can be found on about.gitlab.com/features/#compare "
Regarding the examples please help me understand:
1. Can you rebase in the GitHub interface?
2. Does GitHub have an option to fast forward merges?
3. Please let me know if this is a feature people want open sourced. EDIT turns out that this is part of the open source edition already https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/cont... I created https://gitlab.com/gitlab-org/gitlab-ce/issues/22185 to update the docs
4. We have a commit status API in GitLab CE https://docs.gitlab.com/ce/api/commits.html#commit-status and works with the open source https://github.com/jenkinsci/gitlab-plugin We do have additional integration in EE https://docs.gitlab.com/ee/integration/jenkins.html
BTW you might be happy to learn that what you mention as an example of typical "enterprise-y" feature is available in GitLab CE https://docs.gitlab.com/ce/integration/saml.html
If I'm reading this correctly, this exists in GitLab as an enterprise feature, so I think my earlier comment isn't too far off. There also appears to be some community feedback suggesting this should be a CE feature .
> 2. Does GitHub have an option to fast forward merges?
So is Gitlab's aim to just play catchup to Github?
We have a broader scope than GitHub, see our announcement broadcasted on Tuesday for more information and a demo https://about.gitlab.com/2016/09/14/gitlab-live-event-recap/
Github compromises by having a nice ecosystem of tools which you can plug in, but having it built in is always nice since the integration is tighter.
GitHub (annoyingly) can't do fast-forward merges from non-squashed PRs either.
Display merge request status for builds on Jenkins CI
GitLab implements basically the same API as GitHub for updating build status of commits from external services, or do I misunderstand what feature you mean?
But in general I agree, there are some options GitLab reserved for EE that really feel like they should be part of the CE as well.
And FWIW, I admire GitLab for their open source work. I just think it's worth distinguishing that it's not entirely open source.
When googling for the fast-forward feature one of the top results was this GitHub thread, which had quite a bit of activity fairly recently: https://github.com/gitlabhq/gitlabhq/issues/2324
It seems like many posting there are not aware that this repository/bug tracker is not an official channel anymore -> maybe posting an automated comment in all issues with recent activity or locking them could help avoid confusion? If you arrive via search, you don't see the notice in the main repository description.
They have to make money after all.
The 'basic' product (which is far more than basic) is open source though, which incredible.
I'm not criticizing the product – they're welcome to open or not open source whatever they like. I'm just clarifying the description the parent used.
The review feature is very new in GL, and that plus all of the things you are mentioning within "everything in one spot" is available in this update (except maybe the coding env, not sure what that means anyway), if you've read the announcement. Github also has self hosting.
That's a pretty misleading characterisation. You can browse the source code, submit issues, see what's being worked on, contribute PRs, and freely download and run your own instance of GitLab. A handful of enterprise features aren't open sourced.
GitHub in contrast is a black box.
CE is a very large subset of EE. But yeah, maybe "open core" is a better term.
> except maybe the coding env, not sure what that means anyway
Koding integration (I haven't tried it yet)
> if you've read the announcement
I assume you meant Github's announced features? Yeah, I think they're great.
> Github also has self hosting.
Costs $, Gitlab has free self hosting (updated parent comment)
We've had code review for many years now in GitLab. The coding env probably refers to our integration with Koding, an online IDE https://about.gitlab.com/2016/07/26/koding-and-gitlab-integr...
We have companies scaling their GitHub Enterprise instance up to 25,000 users, and we also have a dedicated Enterprise Support team available 24/5 to resolve any technical issues.
I am not your target market, FWIW, but just a curious developer.
We also recognize that having a SaaS solution like GitHub Organizations meets the needs of many companies (over 75,000 at last count), and our announcement of 2FA enhancements today is an indication of our desire to continue that approach.
(It's of course not certain they are the reason they are moving again, but GitHub looked a lot like the market leader that feels like it doesn't have to bother much anymore. And they weren't entirely wrong.)
GitLab's roadmap yesterday surely didn't motivate or spawn the "New GitHub Universe," and I wouldn't think that Github is very nervous about GitLab currently due to it's massive lead in the market. Maybe this new round of funding made some of the folks at Github look over at Gitlab, but I doubt too much else.
Ehh... dominance among open source projects, and Hacker News and Reddit thread cool points, is one thing. But in boring old terms of actually making money, how IS GitHub doing?
"Enterprise" is practically a swear word here, but that's where the meaningful paying customers are. From my anecdotal experience, Atlassian absolutely dwarfs GitHub in the enterprise world... and that's just the enterprises that are willing to host code in the cloud to begin with.
For large shops demanding an on-prem solution, GitLab seems to have a much better story than GitHub since that's really their business model bread-and-butter. For GitLab, the cloud hosting is basically just a marketing tool.
It's historically been tough to compare them to Atlassian because Atlassian has provided tons of other enterprise services like Jira and Confluence, and an 8 year lead plus going public, but I think Github is definitely working on better squeezing into the enterprise space with this current announcement.
I was recently at an F1000 company and we did self-hosted GitHub Enterprise. While many services were duplicated across departments, there were a variety of other commercial VCS setups, and our GH was not highly available… there was a ton of buy-in to GitHub Enterprise. And, yeah, we did JIRA and Confluence (and SharePoint…).
I'm doing a gig for a F100 company now and, well, we've got GitLab. I dunno if I'm just more used to GitHub or if I actually prefer it to GitLab.
Just my 2 cents, but I think they very well should be
It's always disappointing to see a self-described intellectual community give over so heavily to such an obviously broken thought process, but humans being the emotionally manipulable creatures they are, it makes sense.
A lot of people seems to think they are smart because they belong to a powerful or politically correct group.
Also a lot of people seems to think they are smart because they are rooting for the underdog or just plain contrarian. ; )
and self-hosting :-)
But the answer of self-hosting is a perfectly valid answer for "Why the love for GitLab?" when one = $0 in licensing, and the other = > $2,500/year in licensing.
That is literally what the comment I replied to said. That "self hosting" was a reason to root for gitlab.
Similar to the "you can't use price to differentiate the two" - why not?
doesn't speak well for their business prospects.
GitLab's pricing model won a lot of people when GitHub's was ugly for anyone who wanted private repos (single guy at home with 10+ private repos for things like your dot files, etc? $20+ a month, for what likely amounted to under 1MB of disk space).
Still, most people in HN threads use it because it's free. Which is great for an open source tool, but bad for an unprofitable, VC-funded startup.
Price is a feature.
Maybe they should start looking into global rollout like Google, Facebook and basically every serious company having world-wide audience.
And that’s exactly why you shouldn’t use it.
> Since the open letter to Github with the complaints of feature requests,
This, and the answer from GitLab to that letter, is what made GitHub move in the first place.
You need competition for a healthy market.
Issue tracking, or anything tracking really, document versioning and templates to get you started really quickly. It’s proven scalable as it’s already used by companies with more than 17 000 users with a single instance of Tuleap.
I would love some feedback as we are actively developing it with monthly releases. You can check it out at https://tuleap.org/
This is really not about replacing those services, it's more about building a better foundation for integrators like Waffle and ZenHub to build on.
Our focus is going to remain on how to integrate a full-featured project management suite within the GitHub eco-system. The GitHub projects release will make a great foundation, and ZenHub will be there to provide the more advanced features like issue hierarchy (epics), time estimation and reporting. Lots of exciting releases coming soon for ZenHub users :)
Sure, it won't completely replace them, but GitHub building this as a platform counts as competition.
Shameless plug: Zube has all these things and more - https://zube.io :)
This will inevitably force out GH's integration partners once users start to complain how feature-deficient projects are in their current state.
Even if I could do classes of accounts. Owners and admins, MFA required. Users (bots) that just update CI status, not required.
"We’re rethinking our integrations model to provide better ways for tools to extend and integrate with GitHub. We’ve added the ability for an integration to act on its own behalf instead of impersonating a user—making it a first class actor on GitHub without using a paid seat. Admins will have the ability to configure integrations directly on Organizations and control which repositories they allow access to."
Not so different from human users who have 2FA activated and use the command line to interact with github.
It is the exact same with Google Apps as well (where you add the user to the 2faexceptions group and review+remove them a week later).
I was ready to flip the switch, till I realized that a third-party bot account in our organization doesn't have 2fa. Dropped them a mail, hoping to flip it by tomorrow (100% non-bot users have it enabled, so no one is getting auto-kicked).
JIRA doesn't support markdown. That seems like baby stuff to me.
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.
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.
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.
This sounds like a security nightmare, that also significantly impacts local update times and makes for a huge repo.
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.
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.
Works pretty well, if a little awkward at first.
 - http://purpleapp.com
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.
It sort of boggles the mind, really - and makes me feel like they did not really take the community's desires seriously.
I suspect it's still a lot better than the alternative but not having org-wide Projects is a little sad.
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.
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 should need).
Considering all of the PCI-DSS / HIPAA / SOX / etc. audit points around change control (even ignoring corporate versions of the same) it's practically impossible to add external services to GH and have them be useful while still meeting compliance. Change control is required, but that also implies control of change control. As-is any service could delete all of your content, whether intentionally or inadvertently, or even worse could corrupt or otherwise alter your history.
It may be detectable and recoverable because git, but it would be infinitely easier to have code and PR be r--rw-.
EDIT: This is now a thing, according to @bhuga below. Also, GH is now publishing a roadmap for what's coming down the pipe, so we're not in the dark as to when these critically-important-why-isnt-it-out-yet features are being worked on. https://developer.github.com/early-access/platform-roadmap/
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 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.
Some alternatives that randomly come to mind: "Boards", "Plan", "Plans", "Tasks".
Understandable -- it's clearly companies that are paying the bills these days -- but a little disappointing given the extent to which GitHub got big by attracting lone hackers and little open source projects.
If somebody else manages to claim the small-scale end if the market it could eventually spell trouble for GitHub.
Overall looks good! When does Enterprise get these features? :)
These features will be coming to GitHub Enterprise soon - we always aim to get new features onto the Enterprise platform on the next major release (which occurs every 3 months on average).
- Mobile support: Trello mobile app is great, projects web doesn't even resize for mobile.
- Slack support: Card Created notifications
- Easier “card” preview: Projects requires you to go to a new page to view a card
- Projects (1): This little "1" will always be 1. At least with PRs and Issues it means something (pending tasks, etc).
- Limited to one repo
I also found it funny that they call it "notes" as in "add note" "delete note" etc, but there is a menu item on each card that says "Copy Card URL". Maybe they renamed from "cards" to "notes" mid development? :)
Knowing the conflict is just db/schema version instead of something more problematic-- that is especially handy when used in conjunction with various target branches.
i.e. I know <another-feature> branch is about to be merged before right before <my-branch> gets merged. Then, I can know what I'm going to have to fix quickly without having to go back to terminal, fetch <another-feature>, merge <my-branch>, just to find the conflicts. Yes, I have to do that with master after it's merged anyways, but I find it great to see quickly and at a glance beforehand.
We're aiming to monitor this board as much as possible, but if there other feature asks that come up, feel free to connect with our Support team - they're also available to take your feature asks and report them to our Engineering team.
Edit: I saw an approval email notification on one PR, but not another.
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. :)
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"
10 font sizes is too many for any one page.
I'm not a designer or anything so take my feedback with a grain of salt.
- [ ] Some subtask.
- [x] Another subtask.
Most of the times when I do a review it's not a single comment and right now the workflow is to let the team know on Slack that I am reviewing this.
From the Gif it's not 100% clear what the pending state does but I would want something like blocking the PR until every team member that started reviewing will "release" the PR. I also see the negative side of this of course but I think the positive outweighs the negatives.
When the Review approval is missing or required, please make it clear in the "Pull Requests" list-view by updating the color of the little dot and it's popup description.
Right now the colored dot and its description are only including "Checks" but not "Reviews". It would be nice to have a clear indicator of which Pull Requests are missing a review just by looking at the list.
But good to see GitHub responding - would be keen to hear from bitbucket which I personally use for private repos.
Our in-house automation suites depend on it, so this is a big do not use for us.
I really wish their APIs weren't second class citizens. It takes weeks or months for new features to show up in the API - if at all. I wish there was 1-1 parity with the API.
Given how much iteration we do after an initial ship like this, especially one with as much feedback as code review, we prefer shipping the API after things have solidified and settled down after the wide release.
The "Learn more" button on that banner is a broken link…
(It's a good thing this HN post later directed me to the blog post, as now I've learned from that.)
Let me know if that helps!
- Two feature branches were created based on master at the same time.
- Branch1: committed a change to readme and it's pulled into master via PR.
- Branch2: committed a change to readme, raised a pull request (PR#3), and the diff doesn't show the line that was added with the branch1 pull request.
In this example, the PR is telling me there's a conflict and I need to merge master with the PR branch (this is good). What it doesn't tell me is where the conflict is.
Solution, merge the base branch into the interim PR branch. The result will show you the conflict and properly represents what would happen if this PR is accepted. (Bitbucket does this)
Thanks for following up.
gist of merge master example output: https://gist.github.com/jparmstrong/07cab1a566c5c1495d7c8e07...
I want to setup a repo such that a subset of collaborators (or organization members) can merge reviewed PRs to protected branches. I want the rest of the users to be able to create new branches and submit PRs from them, but _not_ to be able to push to protected branches. They should _only_ be able to land code in protected branches via reviewed PRs (via the merge button).
Is there a way to achieve this now that I'm missing? Gitlab's more granular user roles + permissions allow this.
It's strange that I can edit any of the inline comments, but not the actual review body itself. What if I made a typo there?
Github, please don't blow it.
Edit: Indeed, from the github blog post - "You can also leave a review summary and delete, edit, or bundle comments before you submit them."