Bitbucket has developed a feature that will help you maintain repo cleanliness without the tedious task of closing each branch from the command line.

Now when a pull request is sent across branches, a checkbox will appear giving you the option to close the source branch once the pull request gets accepted. Bitbucket will automatically close the source branch for you, tidying up your team’s repository.

Closing branches after pull requests (until now) has been a manual process that usually never gets done. Save your team time, automate the process, and keep your code organized with the simple click of a box.

Learn more about pull requests and start using this feature today.

We try to keep scheduled maintenance to a minimum.  If you are new to Git and Mercurial, keep in mind one of the advantages of distributed version control systems is the ability to work offline.  You can always commit locally and push to Bitbucket later.

We are sorry for any inconvenience this maintenance window causes. We appreciate everyone’s patience as we continue to improve our infrastructure.

• Changed the UI of the Bookmarks window to improve navigation
• Implemented a clone button in Bitbucket for instant access to your source
• Created a setup wizard to help connect users with their repositories
• Listened to customer input and added advanced Mercurial support
• Implemented commit message drafting to save you time.
• And a whole lot more!

What’s new?

Bookmarks window: reloaded

The bookmarks window has been completely redesigned to improve its visual style and usability.

Search your bookmarks in real time, quickly navigating to the projects you want to find regardless of where they are in the tree. Easily re-sort the contents by name or repository type, and get access to common functions without having to open the full repository window first. You can even invoke Custom Actions directly from the list.

Bitbucket support

Enjoy instant access to your source code by cloning with SourceTree from any repository by simply clicking the ‘SourceTree’ clone option in Bitbucket . Your clone details will automatically be configured in SourceTree for you to instantly download source.

Setup Wizard

To welcome new users to SourceTree and get them up to speed, we now include a setup wizard which packages the steps most people want to perform the first time they open SourceTree. In one short swoop, SourceTree can:

• gather your user details
• configure your accounts on Bitbucket, GitHub, and Kiln
• search your local drive for repositories that you might want to bookmark.

You’ve asked for more Mercurial support, and we have listened. Not to be confused with the bookmarks window, Mercurial has its own concept of bookmarks within a given repository. They behave somewhat like local branches in Git, and they can be used to more easily keep tabs on multiple local streams of development.

Commit message drafts

Now you can start drafting your next commit message long before you’re actually ready to commit. Just click the commit drafting button at the lower-left side of the repository window — or press Cmd-Shift-D, to pop up the drafting pane — and start typing.

Draft commonly used commits and create templates that you can use later to save time. This feature also allows you to refine your commit messages until they are ready for your team to see.

Plenty more!

There are plenty of other small improvements and tweaks in 1.4, and we’ll go into more details in follow-up posts in the coming weeks. In the mean time, we hope you enjoy the new release!

 

• Link commits to JIRA simply by referencing issue keys in commit messages
• Use issue keys in pull requests or changeset comments to clarify the why behind your work
• Map an unlimited number of JIRA, Bamboo, Crucible and Jenkins servers

Today we’re releasing the biggest innovation in DVCS since they added the D. Introducing…Spooning.

Yeah, you heard it correctly, Spooning. DVCS made it damn easy to fork repos and merge changes back to the original author’s code base. But Forking in DVCS is a lonely pursuit, and it’s become so second nature it feels a little boring. So we’re cranking it up a notch with Spooning. Spooning is a pair programming concept, modernized for the world of distributed version control. “Whatever happened to pair programming?” you’re probably asking yourself. Damn good question. People just started forking left and right and everybody forgot the power and utility of working together. WTF?

Spooning is an easy feature to learn, and it has a ton of benefits for developers: speed, comfort and a better position for pull requests. Rather than wax on about it here, head on over to the feature page and watch the overview video. And then fire up your Bitbucket account, and start spooning.

Interested in eating some great food, listening to a sweet DJ and of course having a few beers with the Bitbucket team?

We’ve put together a little contest so that some of you in the SF area can join us in celebrating Atlassian’s new SOMA home and 10 Year Anniversary!

How do I Enter?

If you’re interested in being a part of this euphoric evening, fork this repo, answer some basic questions on how you think we can make Bitbucket better, and then issue a pull request. First 50 to respond will receive an invite to the party.

When and where is the party?

• When: Friday, April 13th @ 5:30pm – 10:30pm
• Where: 1098 Harrison Street, San Francisco

T-shirts anyone?

In addition to attending our awesome party, you’ll receive a free Bitbucket t-shirt in your preferred size.

We’re also co-sponsoring the PyLadies party Saturday night along with SurveyMonkey.  Be sure to stop by the PyLadies booth to pick up a ticket.  We’ll see you at the party!

The four team members attending this year are:

Brodie Rao

Charles McLaughlin

Erik van Zijst

Jesper Nøhr

Using mercurial patch queues and git amend to make better pull requests.

Pull requests have become a bedrock of our team’s development process. However, a large pull request that touches many files and spans multiple commits makes for a difficult diff to review.

Reviewing a pull request is easier if it tells a story, and one great way of doing so is by organizing commits into orthogonal layers and commits that each address one concern. Reviewing the pull request a layer at a time means easier diffs to wrap your head around, and the ability to comment on the individual commits within the pull request.

The mercurial queues (mq) extension for mercurial is a powerful way to manage your work in progress before pushing it to the world. Bryan O’Sullivan’s authoritative introduction to mq in Mercurial: The Definitive Guide is a great reference. The Mozilla Developer Network highlights advanced uses of mq, such as rebasing to resolve patch conflicts.

My pull request story telling begins by thinking about potential layers (for example, front- versus back-end) and considering upfront refactorings that can make the final solution cleaner. It is then a matter of hg qnewing a patch for each refactoring or layer as I go. As I continue to test while developing, bugs in lower layers can be fixed in the most relevant patch by hg qpoping, fixing the bug, then hq pushing.

For example, here’s what my progress in implementing the ability to create a new branch via a pull request looked like:

$ hg qseries
add-boolean-field.patch
logic-to-detect-new-branch-case.patch
toggle-checkbox-on-new-branch-change.patch
show-new-branch-indicator-in-view.patch
compare-view-ajax-url-new-branches.patch
fix-get_compare_url-for-pull-requests.patch

However, fixing lower-layer bugs can sometimes mean subsequent patches in the queue no longer apply cleanly:

$ hg qpush
applying add-boolean-field.patch
patching file apps/compare/forms.py
Hunk #1 FAILED at 0
1 out of 1 hunks FAILED -- saving rejects to file apps/compare/forms.py.rej

We can clean up the failed qpush and take advantage of the fantastic diff-mode for Emacs to repair the patch:

$ hg qpop
$ find . -name '*.rej' | xargs rm
$ emacs .hg/patches/add-boolean-field.patch

Emacs’s diff-mode automatically updates the patch file’s hunk headers (that is, line offsets) when you edit the context surrounding modified lines in a patch. In this case, it’s just a matter of updating the still-fresh-in-my-mind surrounding context that changed.

Finally, using hg qfold can help you combine related patches and hg qrename --edit allows you to craft the commit messages your pull request will use (protip: create an hg qedit alias).

The great news about this kind of workflow is that it’s not just Mercurial martyrs that can benefit: git users have git rebase and git commit --amend at their fingertips to create their own pull request story.

So the next time you’re ready to press the Create pull request button, ask yourself if its story is worth telling.

A few of us on the Bitbucket team have become quite used to using them and found ourselves sad when we wanted to fork a repo or make a pull request and had to reach for the mouse.

We are sad no longer.

The x- action keyboard shortcuts allow you to execute a repository action (compare view, pull request, fork, etc…)

Try them on your repository.