5 ms·

A slightly more generous interpretation — GitHub was pretty much stagnant (for better or worse) until Microsoft took over and started adding new features and ma

A slightly more generous interpretation — GitHub was pretty much stagnant (for better or worse) until Microsoft took over and started adding new features and making improvements are a pretty considerable rate. This has led to more complexity and bugs. I at least have found the recent improvements and additions pretty great — GitHub’s newish PR review UX is way ahead of BitBucket (where my employer currently hosts our codebases) for example.

ollien 4y ago
My employer just moved from Bitbucket (on-prem) to Github (cloud). I have to say, as much as I hated the Bitbucket review system, there's a bunch of things we run into with Github that just are surprisingly lacking compared to Bitbucket. - In Bitbucket, you can reply to _any_ comment as a thread, rather than a quote-reply, making conversations easier to follow. Github only lets you do this if you're replying to a comment on a file. - Though this has been added very recently as a beta addition, the lack of a file tree made large reviews in our monorepo hard to follow. - If someone force-pushes, the UI doesn't tell me what commits were removed; just the new branch-head. - Our devops team has had to make it so we can re-trigger our CI (or add additional pipelines) via comment-commands, while in BitBucket we were able to add custom buttons to the PR menu. This means there's a lot of noise of comments that just say "/retrigger-ci" or some such. - This one is not Github's fault per-say, but because we used to add our users via LDAP, we used to just be able to type <first-initial + last name> to add a user to a PR, but now because everyone has bespoke usernames, it's a lot more annoying to add people because I now have to also remember their username. - In our repo, we work with lots of release branches for maintenance (committing to `develop` is not rare, but quite frequently we're adding features to old branches), and Github's PR view does not show the target branch at a glance, which can be annoying if someone has multiple PRs to cherry-pick a commit across branches and you don't know which PR you're clicking on. - Being a cloud solution, we can't add pre-receive hooks. We previously used to reject commits at push-time that didn't follow the format we use for time/issue tracking. Now, we have to enforce this in CI which means rebasing/force pushing to fix it. While pre-commit hooks can help, this depends on every developer keeping their hooks up to date, which is a challenge. That said, Github's "review" system, rather than limiting you to only individual comments, is great for email noise.
- ramraj07 4y ago
  I think your answered your own question with saying you have a monorepo on GitHub. Like it’s not designed for that at all? That’s the main reason I’m not yet pushing for monorepos in our org, because it looks like it’ll be inviting trouble if we are still using GitHub for it. Also you’re not doing trunk? I mean I get it it’s hard but sounds like a no brainer thing to stop doing as soon as possible..
  - ollien 4y ago
    > Like it’s not designed for that at all? The PR workflow certainly isn't, but we're far from the only company using them (Dropbox comes to mind). It's surprising to see it not fully supported. > Also you’re not doing trunk? I mean I get it it’s hard but sounds like a no brainer thing to stop doing as soon as possible.. No, unfortunately not. Trust me, you're preaching to the choir :) But unfortunately, long-lived branches is the workflow we're stuck with at the moment (we constantly merge commits forward, but it's a manual process). That said, even if we were using short-lived feature-branches, you wouldn't be able to know from the PR view if a commit was to a feature branch or not, so the criticism still applies.
- mhitza 4y ago
  > - Our devops team has had to make it so we can re-trigger our CI (or add additional pipelines) via comment-commands, while in BitBucket we were able to add custom buttons to the PR menu. This means there's a lot of noise of comments that just say "/retrigger-ci" or some such. Job re-runs are more than one click away unfortunately. But I'd be curious, outside a failing job due to flakiness or GitHub instability; for what other reason do you use this functionality?
  - ollien 4y ago
    The big one that I can think of is triggering our "packaging" pipelines. We have some packages published separately from our main releases (which are not published via CI), so we have to trigger separate pipelines for them. We could _probably_ have some kind of filter based on directories, and honestly I'm not sure why we don't (probably so it's deliberate). Anyway, hope that answers your question :)

ollien 4y ago

My employer just moved from Bitbucket (on-prem) to Github (cloud). I have to say, as much as I hated the Bitbucket review system, there's a bunch of things we run into with Github that just are surprisingly lacking compared to Bitbucket. - In Bitbucket, you can reply to _any_ comment as a thread, rather than a quote-reply, making conversations easier to follow. Github only lets you do this if you're replying to a comment on a file. - Though this has been added very recently as a beta addition, the lack of a file tree made large reviews in our monorepo hard to follow. - If someone force-pushes, the UI doesn't tell me what commits were removed; just the new branch-head. - Our devops team has had to make it so we can re-trigger our CI (or add additional pipelines) via comment-commands, while in BitBucket we were able to add custom buttons to the PR menu. This means there's a lot of noise of comments that just say "/retrigger-ci" or some such. - This one is not Github's fault per-say, but because we used to add our users via LDAP, we used to just be able to type <first-initial + last name> to add a user to a PR, but now because everyone has bespoke usernames, it's a lot more annoying to add people because I now have to also remember their username. - In our repo, we work with lots of release branches for maintenance (committing to `develop` is not rare, but quite frequently we're adding features to old branches), and Github's PR view does not show the target branch at a glance, which can be annoying if someone has multiple PRs to cherry-pick a commit across branches and you don't know which PR you're clicking on. - Being a cloud solution, we can't add pre-receive hooks. We previously used to reject commits at push-time that didn't follow the format we use for time/issue tracking. Now, we have to enforce this in CI which means rebasing/force pushing to fix it. While pre-commit hooks can help, this depends on every developer keeping their hooks up to date, which is a challenge. That said, Github's "review" system, rather than limiting you to only individual comments, is great for email noise.

ramraj07 4y ago
I think your answered your own question with saying you have a monorepo on GitHub. Like it’s not designed for that at all? That’s the main reason I’m not yet pushing for monorepos in our org, because it looks like it’ll be inviting trouble if we are still using GitHub for it. Also you’re not doing trunk? I mean I get it it’s hard but sounds like a no brainer thing to stop doing as soon as possible..
- ollien 4y ago
  > Like it’s not designed for that at all? The PR workflow certainly isn't, but we're far from the only company using them (Dropbox comes to mind). It's surprising to see it not fully supported. > Also you’re not doing trunk? I mean I get it it’s hard but sounds like a no brainer thing to stop doing as soon as possible.. No, unfortunately not. Trust me, you're preaching to the choir :) But unfortunately, long-lived branches is the workflow we're stuck with at the moment (we constantly merge commits forward, but it's a manual process). That said, even if we were using short-lived feature-branches, you wouldn't be able to know from the PR view if a commit was to a feature branch or not, so the criticism still applies.
mhitza 4y ago
> - Our devops team has had to make it so we can re-trigger our CI (or add additional pipelines) via comment-commands, while in BitBucket we were able to add custom buttons to the PR menu. This means there's a lot of noise of comments that just say "/retrigger-ci" or some such. Job re-runs are more than one click away unfortunately. But I'd be curious, outside a failing job due to flakiness or GitHub instability; for what other reason do you use this functionality?
- ollien 4y ago
  The big one that I can think of is triggering our "packaging" pipelines. We have some packages published separately from our main releases (which are not published via CI), so we have to trigger separate pipelines for them. We could _probably_ have some kind of filter based on directories, and honestly I'm not sure why we don't (probably so it's deliberate). Anyway, hope that answers your question :)