kannonboy

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!

The same authors also created Infinigen Indoors[1] to generate indoor scenes for computer vision applications such as robotics & AR.

[1] https://arxiv.org/abs/2406.11824

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.

Hey folks, Atlassian employee here! This isn't official comms but I wanted to identify myself in case there's any confusion :)

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.

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.

Disclosure: I worked on JIRA's DVCS integration.

edit: fixed formating

Thanks! Just Keynote & GIMP on macOS

Thanks Peff, congrats on the great release!

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.

[0]: https://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_col...

[1]: https://en.wikipedia.org/wiki/Birthday_problem#Square_approx...

Great write-up! I love the focus on performance in this release.

I've put together another write-up of the Git 2.11 release that discusses some of the other new features (and goes into a little more detail on some of the 'sundries'): https://medium.com/@kannonboy/whats-new-in-git-2-11-64860aea...

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.

Comic author here. For the command-line I use a post-checkout hook to display the build status of a commit whenever I switch commits:

https://bitbucket.org/tpettersen/bitbucket-build-status-hook

That way if I update master before starting on a new feature, I get a notification if the tip of master is broken (or still building).

Aerobatic (https://www.aerobatic.com/) takes a similar, though slightly more flexible, approach with their static site deployments for Bitbucket.

You pick a branch then (optionally) specify a sub-directory of your repository to deploy.

(full disclosure: I'm at Atlassian)

In fact, we just launched Hg support for Bitbucket's built-in CI/CD, Bitbucket Pipelines:

https://blog.bitbucket.org/2016/07/26/bitbucket-pipelines-be...

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.

[0]: https://blog.bitbucket.org/2015/10/01/contributing-to-git-lf...

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].

[0]: https://bitbucket.org/product/features/pipelines

Bitbucket engineer here!

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.

[0]: https://confluence.atlassian.com/bitbucketserver/bitbucket-s... [1]: https://developer.atlassian.com/blog/2015/01/a-better-pull-r...

edit: correcting my previous statement on diff sizing in Bitbucket Cloud

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.

[0]: https://confluence.atlassian.com/bitbucketserver/bitbucket-s...

Thanks for your thoughts debacle! Let me address them slightly out of order:

> Each individual Atlassian tool has enough minor style differences to make the ecosystem feel less cohesive.

I think the minor style differences are in part an artifact of our design process. We have a fairly large portfolio of products these days, and try to avoid dependencies between the release timelines and roadmaps of each. This means that a new design pattern or improvement will often appear in one product several releases before it is syndicated elsewhere. The way this often works on the ground is that a designer will invent a new pattern in one product, see it implemented and shipped, and then later abstracted and incorporated into the Atlassian Design Guidelines and Atlassian UI library that ships with all of our products.

> Administration of your software is opaque, to put it nicely.

Simplifying administration (particularly initial setup) has been a long-time focus of ours, so much so that we codified it into our design principles as "Gracefully reveal depth"[0]. But it's a tough proposition: JIRA is powerful and flexible, but seriously complex, and we're still figuring out how to ease administration without removing or reducing functionality that our customers rely on. We're getting there (check out the admin console in JIRA 7 vs JIRA 6, or any other two consecutive major versions) but I think it will be more or less a constant battle as the products continue to expand in functionality. I appreciate the time you've taken to provide the feedback already, but if you have any specific pain points regarding administration I'd love to hear them.

> All of your tools feel dated and cold. The blue "metro" style design reminds me of Trello's design, and not in a good way.

> It seems as though you use color as a crutch for poor layout. GitHub is fixed width and Bitbucket is fluid but I see so much more on my GitHub homepage than on my Bitbucket homepage.

> There is a stark difference in the experience in navigating both sites. GitHub seems to have to put a lot of thought into page real estate value. Bitbucket in contrast is much more spartan.

I'm personally not an aesthete in any sense of the word, but this seems valuable feedback. I'll bring it to the attention of our design and brand teams (and see if I can get them to jump in and comment). Thanks again for the feedback mate.

[0]: https://design.atlassian.com/how-we-design/principles/

They stand for "Type" and "Priority". I believe they're abbreviated to give you maximum space for the issue title, if you hover over the column header you'll see the full column name - but I agree that's not an ideal first impression.

Now that you mention it I agree that in the "Priority" column in particular it can be a bit tricky to differentiate between some of the values ("Minor" and "Trivial" in particular). These have recently been replaced with some much more easily distinguishable ones in JIRA[0], which I'm sure will make it to Bitbucket soon. Thanks for the feedback! I'll pass it on to the designers of both the JIRA & Bitbucket teams.

[0]: http://i.imgur.com/R4dbC9B.png

Hi adnanh, Bitbucket dev here. I agree we have a different UI to GitHub, but horrific seems a little strong. Our designers & front-enders spend a lot of time pixel pushing to build out a UX focused on professional teams. We even have a public set of design patterns and guidelines that apply across all of our products[0] if you're curious. That said, we are always iterating on the design and you are of course entitled to your own opinion. I'd appreciate any specific feedback you could give us on the UI/UX if you'd care to elaborate?

[0]: https://design.atlassian.com/