From the homepage it sounds like they've prioritised geometry fidelity for CV research rather than performance:
> Infinigen is optimized for computer vision research, particularly 3D vision. Infinigen does not use bump/normal-maps, full-transparency, or other techniques which fake geometric detail. All fine details of geometry from Infinigen are real, ensuring accurate 3D ground truth.
So I suspect the assets wouldn't be particularly optimised for video games. Perhaps a good starting point though!
I love that the view count is included in the minimalist UI. I came across one with zero views, and there's something so intimate and exciting about being the first person to watch an ancient home video (even if it's shaky handycam footage of a horse, narrated in Russian).
As an aside, hats off to Google to being able to serve an 11 year old video with no noticeable delay from what must be the coldest of caches.
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.
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.
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].
In Bitbucket Cloud - i.e. bitbucket.org - we cap the diff size for pull requests at 10000 lines.
In Bitbucket Server we also cap the number of lines in a particular diff at 10000 by default, but you can override this number[0], along with all other timeouts and thresholds with our various configuration properties. One of the engineering values of the Server team is "no hardcoded constants" - so you can configure basically any property that you like to suit your particular deployment.
Both Bitbucket Server and Cloud also generate a subtly different - and in our opinion more correct - diff than you'll find in GitLab and GitHub. Bitbucket actually creates a hypothetical merge commit between your two branches and shows the diff between it and the tip of the target branch. This means we can nicely render merge conflicts in the UI, and show how your target branch will actually be affected by the merge (rather than just the changes on the source branch). I wrote an article that discusses our merge algorithm in more depth[1] a little while ago.
Nice one! I'm a developer from Atlassian, it's cool to see the different CI/CD applications that Pipelines is being used for.
Regarding static site deployment specifically, Aerobatic (https://www.aerobatic.com/) have a similar static site publishing offering via a Bitbucket add-on, though it uses Lambda rather than Pipelines. They've got a couple of other nifty features like auto-renewing SSL certificates, too.
I suspect this repository has the issue tracker mode set to "private". If the owner changes it to "public" issues will be anonymously accessible: http://i.imgur.com/JqCvXNU.png
Actually Bitbucket Server (née Stash) already supports squashing and a variety of other pull request merge strategies. They're just configured[0] per repository, project or globally rather than an explicit option at merge time.
> Infinigen is optimized for computer vision research, particularly 3D vision. Infinigen does not use bump/normal-maps, full-transparency, or other techniques which fake geometric detail. All fine details of geometry from Infinigen are real, ensuring accurate 3D ground truth.
So I suspect the assets wouldn't be particularly optimised for video games. Perhaps a good starting point though!