Code on Launchpad Blog

Review merge proposals in VS Code

Adam Steciuk — Tue, 08 Sep 2026 10:32:27 +0000

Launchpad Merge Proposals, a VS Code extension for reviewing Launchpad merge proposals, is now available on the Visual Studio Marketplace as a preview release.

The extension brings the review into the editor. It finds the merge proposals for the branch you have checked out, renders their diffs in VS Code’s diff editor, and lets you comment and vote without opening a browser.

What the extension does

Finds the merge proposals for the branch you are on

It reads the upstream of the checked-out branch and lists merge proposals in both directions: outgoing, where your branch is the source, and incoming, where it is the target. Proposals can be filtered by status.

Renders diffs in the VS Code editor

Open Files Changed and the proposal opens in VS Code’s side-by-side diff editor, with syntax highlighting and the surrounding file for context. Files are decorated to show where comments already exist.

Puts comments next to the code

Published inline comments appear beside the lines they refer to, and new ones are drafted in the same place, with full markdown support. Drafts are stored on Launchpad, so a review started in the editor can be finished in the browser, or the other way around.

Submits the whole review at once

Pick a vote, write the summary comment, and submit. Every inline draft is published alongside it.

Getting started

Install Launchpad Merge Proposals in VS Code 1.105 or newer.
Open a project backed by a Git repository on Launchpad, and check out a branch tracking a remote one.
Open the Launchpad Merge Proposals view from the Activity Bar and sign in when prompted.
Select a merge proposal, then pick a preview diff to see the changes and comments.

Sign-in uses Launchpad’s OAuth flow, and the token is stored in VS Code’s secret storage. Launchpad asks what level of access to grant, and the level you pick determines what the extension can do. Reading diffs and published inline comments needs at least read access. Drafting inline comments and submitting reviews needs change access.

Current status of the project

This is a preview release. The core review flow works and we use it daily, but some capabilities are still experimental while we work out how they should behave. The README covers the current state, including a known issues section that we update with each release.

Feedback

We want to hear what works, what breaks, and what is missing. Please report bugs and file feature requests on the project’s Launchpad page.

The extension is free software under GPL-3.0, and its source is hosted on Launchpad. We welcome contributions via merge proposals. You can even review them using the extension itself!

Merge Launchpad merge proposals with one click

Goulin Khoge — Fri, 04 Sep 2026 09:52:42 +0000

Maintainers can now merge changes (merge proposals) directly from the Launchpad UI.

The new Request merge button is available to anyone with permission to push to the target branch. Launchpad enables it if the merge proposal has:

An active status and an up-to-date diff
No conflicts with the target branch
Approval from the target repository owner, a member of its owner team, or designated review team
Successfully completed any configured CI checks
No unmerged prerequisite branches

When you click on Request merge, Launchpad queues the merge, tracks its progress, and lets you know when the change has been merged.

The feature is available for all Launchpad-hosted Git repositories, with no additional setup or integration required.

Happy merging!

Git Protocol v2 Available at Launchpad

Thiago F Pappacena — Mon, 28 Sep 2020 13:26:21 +0000

After a few weeks of development and testing, we are proud to finally announce that Git protocol v2 is available at Launchpad! But what are the improvements in the protocol itself, and how can you benefit from that?

The git v2 protocol was released a while ago, in May 2018, with the intent of simplifying git over HTTP transfer protocol, allowing extensibility of git capabilities, and reducing the network usage in some operations.

For the end user, the main clear benefit is the bandwidth reduction: in the previous version of the protocol, when one does a “git pull origin master”, for example, even if you have no new commits to fetch from the remote origin, git server would first “advertise” to the client all refs (branches and tags) available. In big repositories with hundreds or thousands of refs, this simple handshake operation could consume a lot of bandwidth and time to communicate a bunch of data that would potentially be discarded by the client after.

In the v2 protocol, this waste is no longer present: the client now has the ability to filter which refs it wants to know about before the server starts advertising it.

The v2 protocol is not the default on git clients yet, but if you are using a git version higher than 2.19, you can use v2: simply run git config --global protocol.version 2, and you will be using the most recent protocol version when communicating with servers that support this version. Including Launchpad, of course.

And even if you have repositories hosted in a server that is not yet compatible with v2, don’t worry: the git client is backward compatible. If the server does not support v2, git client should fall back gracefully to the previous version and everything should continue to work as expected. We hope you enjoy the new feature. And let us know if you have any feedback!

Git per-branch permissions

Colin Watson — Thu, 10 Jan 2019 20:41:08 +0000

We’ve had Git hosting support in Launchpad for a few years now. One thing that some users asked for, particularly larger users such as the Ubuntu kernel team, was the ability to set up per-branch push permissions for their repositories. Today we rolled out the last piece of this work.

Launchpad’s default behaviour is that repository owners may push anything to their own repositories, including creating new branches, force-pushing (rewriting history), and deleting branches, while nobody else may push anything. Repository owners can now also choose to protect branches or tags, either individually or using wildcard rules. If a branch is protected, then by default repository owners can only create or push it but cannot force-push or delete; if a tag is protected, then by default repository owners can create it but cannot move or delete it.

You can also allow selected contributors to push to protected branches or tags, so if you’re collaborating with somebody on a branch and just want to be able to quickly pair-program via git push, or you want a merge robot to be able to land merge proposals in your repository without having to add it to the team that owns the repository and thus give it privileges it doesn’t need, then this feature may be for you.

There’s some initial documentation on our help site, and here’s a screenshot of a repository that’s been set up to give a contributor push access to a single branch:

Git-to-Git imports

Colin Watson — Wed, 16 Nov 2016 06:48:05 +0000

Launchpad has had Git-to-Bazaar code imports since 2009, along with imports from a few other systems. These form part of Launchpad’s original mission to keep track of free software, regardless of where it’s hosted. They’re also very useful for automatically building other artifacts, such as source package recipes or snap packages, from code hosted elsewhere. Unfortunately they’re quite complicated: they need to be able to do a full round-trip conversion of every revision from the other version control system, which has made it difficult to add support for Git features such as signed commits or submodules. Once one of these features is present anywhere in the history of a branch, importing it to Bazaar becomes impossible. This has been a headache for many users.

We can do better nowadays. As of last year, we have direct Git hosting support in Launchpad, and we can already build snaps and recipes straight from Git, so we can fulfil our basic goal more robustly now with a lot less code. So, Launchpad now supports Git-to-Git code imports, also known as Git mirroring. You can use this to replace many uses of Git-to-Bazaar imports (note that there’s no translations integration yet, and of course you won’t be able to branch the resulting import using bzr).

See our Git documentation for more details.

Linking Git merge proposals to bugs

Colin Watson — Thu, 08 Sep 2016 14:21:06 +0000

We just rolled out a new feature for Launchpad’s Git repository hosting: Git-based merge proposals can now be linked to Launchpad bugs. This can be done manually from the web UI for the merge proposal, but normally you should just mention the Launchpad bug in the commit message of one of the commits you want to merge. The required commit message text to link to bugs #XXX and #YYY looks like this:

LP: #XXX, #YYY

This is the same form used for Launchpad bug references in debian/changelog files in source packages, and the general approach of mentioning bugs in commit messages is similar to that of various other hosting sites.

Bugs are not automatically closed when merge proposals land, because the policy for when that should happen varies from project to project: for example, projects often only close bugs when they make releases, or when their code is deployed to production sites.

Users familiar with Bazaar on Launchpad should note that the model for Git bug linking is slightly different: bugs are linked to merge proposals rather than to individual branches. This difference is mainly because individual branches within a Git repository are often much more ephemeral than Bazaar branches.

Documentation is here, along with other details of Launchpad’s Git hosting.

Beta test: Git recipes

Colin Watson — Mon, 25 Jan 2016 11:33:41 +0000

If you are a member of Launchpad’s beta testers team, you can now try out Git-based recipes. These work very similarly to the Bazaar-based recipes that Launchpad has supported for a long time, with a few minor changes to handle differences in the underlying version control system: the main thing you’ll probably notice is that you almost always need to explicitly specify a branch name. The recipes documentation explains what to do; if you’re already familiar with how recipes work for Bazaar, then you should probably skip straight to the recipes guide to look over the differences for Git.

Please try this out and report any bugs you find. If all goes well, we’ll open this up to all users in a couple of weeks.

Update: as of 2016-03-15, this feature is enabled for all Launchpad users.

Beta test: webhooks

Colin Watson — Mon, 09 Nov 2015 15:41:34 +0000

If you are a member of Launchpad’s beta testers team, you can now try out webhooks for Bazaar branches and Git repositories. These can be used to set up integration with external sites for various purposes, such as running CI jobs or publishing documentation. We expect to open this up to all Launchpad users soon, but in the meantime please do file a bug against Launchpad itself if you encounter any problems.

See our webhooks documentation for more details.

Update: as of 2015-11-20, this feature is enabled for all Launchpad users.

Launchpad news, April-June 2015

Colin Watson — Thu, 09 Jul 2015 01:07:23 +0000

It’s been a while since we posted much regularly on this team blog, not least because for a while Launchpad was running more or less in maintenance mode. That’s no longer the case and we’re back to the point where we can do feature development work again, as exemplified by our recent addition of Git code hosting support.

Lots of other things have been happening in the Launchpad world lately, though, and the half-way point in the year seems like a good time to start talking about them. I’m going to try to do this a bit more regularly, aiming for about once a month when we also update our internal stakeholders. This post covers roughly the last three months.

Git

Of course, you don’t get to release a major new feature and then have everything be perfect. In fact, we’d released it pretty much as soon as we had a minimum viable product, so we knew there was plenty more to do.

Now that the basics work reasonably well, we’ve been focusing on tying off loose ends, and on getting to the point where Launchpad itself can be self-hosted in Git: this is partly because most of the things we need to do for that are relevant to many other projects considering a migration, partly because that ensures that any problems with it will affect Launchpad developers directly, and partly because this will allow us to trim a very large amount of database cruft associated with the representation of Launchpad’s own branches.

Here’s a brief changelog since our initial public announcement:

Leaving the “Target reference path” field empty when proposing a Git-based merge proposal no longer crashes (#1451068)
Git-based merge proposals can be deleted
Pushing to private repositories no longer hangs (#1451107)
The backend now stores reflogs so that we can help users recover from mistakes
Pushing a new default repository for a project now sets the repository owner to the project owner rather than to the person performing the push
The project +sharing view now handles Git repositories
Branches of a project default repository are now shown on the project’s code page, although we expect to be making significant further improvements in this area soon
Individual Git commits under “Recent Commits” now link directly to a full view of the corresponding commit
Merge proposal listings now cover Git (#1453020)
Branches in private repositories now show a privacy banner (#1457553)
Repositories can now be deleted (#1456583)
Private repositories are now browseable and show a privacy banner in the browsing interface
The URLs for Git-based merge proposals have moved to be directly under the source repository rather than under the source branch, so that historical MPs can still be accessed after deleting the branch (#1456589)
Launchpad now sends mail for Git-based merge proposals
There are various new Git repository listing views, chiefly for projects, packages, and people
Repositories now have a complete edit form allowing you to rename them, move them between targets, and set their default branch (“HEAD”) (#1456625)
We’ve exported a few more bits and pieces on the webservice API to support Git merge robots
We’ve brought various bits of automation for Git-based merge proposals up to par with their Bazaar equivalents: when a Git branch is updated, Launchpad now automatically updates the preview diffs for any MPs where that is the source branch, and detects whether any MPs where that is the target branch can now be marked as Merged
The Code settings view for projects now allows you to set the project’s default Git repository and to choose whether the default revision system for the project is Bazaar or Git

We’ve started on support for webhooks, and hope to be able to tell you more about this soon. Git-to-Git repository mirroring and native Git recipes are also frequent requests that we know are important to people, and we hope to get to those soon.

Other code review changes

Many of the changes needed for Git touched on our code review infrastructure, but we’ve been making some other improvements there too. Launchpad has supported “inline comments” on merge proposals for a year or so now, allowing you to comment on parts of a diff without having to manually quote it; but the feature hadn’t been quite finished and lots of people had nits to pick with it. We’ve made a couple of improvements here lately:

Preview diffs in merge proposals now have keyboard navigation to move between files, diff hunks, and inline comments
Links to diffs now include a per-file diffstat under an expander triangle
The mails sent when a reviewer adds inline comments now only include relevant parts of the diff context rather than the entire diff, making them much easier to read and making it harder to miss comments (#1334577)

We threw in a couple of bonus features here as well. You can now see side-by-side diffs for merge proposals as well as unified diffs (#917502): there’s a link at the top of each preview diff allowing you to switch it to side-by-side mode (we may add a user preference for this later). And resubmitting a merge proposal now automatically preserves the commit message (#676769).

Package build infrastructure

When we first added support for building debug symbol packages (ddebs) in Ubuntu, we handled the build and publication side of things with a temporary hack involving a custom hack to our sbuild fork that stashed the ddebs on the builder for a while, and a job that periodically fetched them to ddebs.ubuntu.com. As is the way of temporary hacks, it proceeded to stay that way for eight and a half years. It mostly worked, but was rather fragile, contributed to tying us to an old sbuild, wasn’t very extensible to PPAs, and couldn’t work with virtualised builders where all the builder’s state is reset before every build.

A couple of years ago we put together the Launchpad changes required to store ddebs straightforwardly in Launchpad instead, but weren’t able to deploy this at the time due to needing better librarian infrastructure. We finally got all this cleared out in April and deployed the new ddeb publishing mechanism. The main user-visible effect of this is that ddebs.ubuntu.com isn’t liable to lose packages any more, and ddebs are also available from Launchpad build pages.

Having done this, we were able to upgrade from our 2004-era fork of sbuild to a modern version, which fixed a number of long-standing bugs.

All architectures are now optional for PPAs (#1244868), so, for example, a PPA that only needs to support armhf can save builder cycles by disabling amd64 and i386. At the moment this can only be done by Launchpad administrators, so ask a question on Launchpad if you think this would be worth doing for any of your PPAs.

We rewrote the way that we install build-dependencies for source package recipes. This allows recipes to handle the “:native” qualifier in build-dependencies which is used in some places as part of supporting cross-building.

The next step in this modernisation programme will be to move all builds into ScalingStack and decommission the corresponding bare-metal builders, which we’ll be starting soon and working on an architecture-by-architecture basis as that cloud gains support for them. In the short term, this will give us better build capacity on the migrated architectures; in the longer term, it will let us support PPA builds on more architectures, and erase the cumbersome distinction between “non-virtualised” and “virtualised” builders. More news on this as it happens.

Performance

We upgraded to significantly more modern database servers earlier this year, which meant that a lot of hitherto difficult timeout problems suddenly either disappeared or became tractable. There are still some bad queries and a few mysterious problems, but as a general trend our timeout rates are very significantly down from where they were six months ago. We have some more general plans in this area, and will continue to spot-fix bad pages as they show up and as time permits.

Epilogue

We have lots more to do across the whole application, but still have a rather limited number of developers. If any of this kind of thing sounds interesting and you’d like to help, you can!

Git code hosting beta

William Grant — Fri, 01 May 2015 20:50:11 +0000

Today we’re announcing early support for hosting Git repositories directly on Launchpad, as well as or instead of Bazaar branches. This has been by far the single most commonly requested feature from Launchpad code hosting for a long time; we’ve been working hard on it for several months now, and we’re very happy to be able to release it for general use.

This is distinct from the facility to import code from Git (and some other systems) into Bazaar that Launchpad has included for many years. Code imports are useful to aggregate information from all over the free software ecosystem in a unified way, which has always been one of the primary goals of Launchpad, and in the future we may add the facility to import code into Git as well. However, what we’re releasing today is native support: you can use git push to upload code to Launchpad, and your users and collaborators can use git clone to download it, in the same kind of way that you can with any Git server.

Our support is still in its early stages, and we still have several features to add to bring it up to parity with Bazaar hosting in Launchpad, as well as generally making it easier and more pleasant to use. We’ve released it before it’s completely polished because many people are clamouring to be able to use it and we’re ready to let you all do so. From here on in, we’ll be adding features, applying polish, and fixing bugs using Launchpad’s normal iterative deployment process: changes will be rolled out to production once they’re ready, so you’ll see the UI gradually improving over time.

What’s supported?

You can:

push Git repositories to Launchpad over SSH
clone repositories over git://, SSH, or HTTPS
see summary information on repositories and the branches they contain in the Launchpad web UI
follow links from the Launchpad web UI to a full-featured code browser (cgit)
push and clone private repositories, if you have a commercial subscription to Launchpad
propose merges from one branch to another, including in a different repository, provided that they are against the same project or package

What will be supported later?

Launchpad’s Bazaar support has grown many features over the years, and it will take some time to bring our Git support up to full parity with it and beyond. Git repositories use a somewhat different model from Bazaar branches, which we’ve had to account for in many places, and some facilities will require complete reimplementation before we can support them with Git.

Here’s an incomplete list of some of the features we hope to add:

useful subscriptions (currently only attribute change notifications work, which are not usually very interesting in themselves)
RSS feeds
mirroring
webhooks
an integrated code browser

See our help page for more known issues and instructions on using Launchpad with Git.

Helping out

This is a new service, and we welcome your feedback: you can ask questions in #launchpad on freenode IRC, on our launchpad-users mailing list, or on Launchpad Answers, and if you find a bug then please tell us about that too.

Launchpad is free software, licensed under the GNU AGPLv3. We’d be very happy to mentor people who want to help out with parts of this service, or to build things on top of it using our published API. Some preliminary documentation on this is on our developer wiki, and you can always contact us for help.