There are a couple of workarounds documented on it until we reach a proper resolution.
As to the concern around permissions, I believe the reason we're requesting both read and write access to GitHub repositories is that their OAuth implementation bundles the read & write scopes together (https://developer.github.com/apps/building-oauth-apps/unders...). There's just no way to request _just_ read access to repository metadata, which is all the Smart Link feature actually requires.
For Google Drive, which supports more granular scopes, we request _only_ read access, not write access as the title of this post implies.
Possibly not quite what you were after, but JIRA integrates almost as well with GitHub/GitHub:Enterprise as it does with Bitbucket/Bitbucket Server.
With GitHub + JIRA you get:
- associated branches, commits, and pull requests displayed on the JIRA issue view
- the ability to search for issues based on whether they have branches, commits, or pull requests associated with
them
- the "Release Hub", which tracks issues that have outstanding pull requests, or have code but no pull request
- automatic issue transitions, which transition JIRA issue status based on repository events
It's flexible, but the usual automatic issue transition workflow is:
branch created: issue -> "In Progress"
pull request created: issue -> "In Review"
pull request merged: issue -> "Done"
Which works just as well with GitHub as it does with Bitbucket.
The main thing that Bitbucket + JIRA's integration adds is backlinks from Bitbucket to JIRA. Plus the ability to create branches in your Bitbucket repositories directly from JIRA.
If you're dead set on GitHub over Bitbucket, the best way to get "Atlassian" features is to adopt the Atlassian suite and replace GitHub with Bitbucket.
That is a nice writeup. One of the interesting things for me was to see which topics you decided to cover and which to omit. For instance, I noted `clone --reference --recurse-submodules` as a potential topic of interest, but I am afraid to point anybody to the `--reference` option due to its hidden dangers.
I'm also curious how you came up with 19,290 for a birthday paradox on a 7-hex hash. I think it's 16,384, but probability can sometimes be tricky. :)
I came up with 19,290 using the generalized birthday formula[0] (actually after double-checking it's slightly closer to 19,291).
16,384 is the value you get using the square approximation method[1] which I believe is a bit less accurate in terms of probability, but faster to calculate. I think Git's using square approximation under the hood -- which is probably a good thing since I think it'll always yield a more conservative result.
Absolutely. An alternative title for the comic would be "For the love of branch permissions". The second developer in the comic is doing the right thing by creating a feature branch.
However even in a strict branching workflow, there's still a chance you'll have genuine integration failures when two branches are merged, even if they independently pass the tests.
I totally agree it should have been a merge request and the master branch should be protected so novices can't merge to it.
There is a chance that the merge itself breaks the build. I must say that in practise we don't often see this. Maybe because we keep our branches small. Other people seem to be more aware of this problem https://gitlab.com/gitlab-org/gitlab-ce/issues/4176
Hi timv, Bitbucket engineer here. I'm not on the PM team, but to my knowledge we have no plans to discontinue Hg support. The Bitbucket repo population is roughly 90% Git and 10% Mercurial, but due to our scale that is still a freaking huge number of Hg repos. We also hired one of the core Mercurial contributors last year to ensure we continue to improve our offering for both DVCSs. Of course I can't personally guarantee anything, but if I were an Hg user, I'd feel pretty confident that Bitbucket's support isn't going anywhere in the foreseeable future.
I'm an Atlassian engineer & heavy Aerobatic user. It's very nicely integrated with Bitbucket, and has great support for Jekyll, Hugo, and arbitrary npm builds. It also has some advantages over github.io like being able to deploy multiple feature branches from the same repository to separate sites, so you can have separate "staging" and "production" versions.
It is a paid offering, though you get two repositories free, and is very pretty reasonably priced beyond that.
One of the nice things about Git is that it's an extremely portable data format, so vendor lock-in between Bitbucket, GitLab & GitHub isn't too big a deal. There may be a little project metadata that needs to be migrated using an importer, but your source code will always be inherently transferable. It's one of the big reasons Atlassian decided to partner with GitHub on Git LFS[0] rather than pursue our own solution: we didn't want to reduce Git's portability by creating multiple competing standards for large file storage.
Bitbucket engineer here. Not to derail, but since Bitbucket has been brought up a few times in this thread and we're talking differentiating features this seems relevant: Bitbucket also has native Docker-based CI/CD in the form of Bitbucket Pipelines[0].
As is pointed out elsewhere on this thread, we're tracking the request to disable the feature here: https://jira.atlassian.com/browse/CONFCLOUD-67922
There are a couple of workarounds documented on it until we reach a proper resolution.
As to the concern around permissions, I believe the reason we're requesting both read and write access to GitHub repositories is that their OAuth implementation bundles the read & write scopes together (https://developer.github.com/apps/building-oauth-apps/unders...). There's just no way to request _just_ read access to repository metadata, which is all the Smart Link feature actually requires.
For Google Drive, which supports more granular scopes, we request _only_ read access, not write access as the title of this post implies.