git ubuntu clone

git ubuntu clone

This is the second post in a collaborative series between Robie Basak and myself to introduce (more formally) git ubuntu to a broader audience. There is an index of all our planned posts in the first post. As mentioned there, it is important to keep in mind that the tooling and implementation are still highly experimental.

In this post, we will introduce the git ubuntu clone subcommand and take a brief tour of what an imported repository looks like. git ubuntu clone will be the entry point for most users to interact with Ubuntu source packages, as it answers a common request on IRC: “Where is the source for package X?”. As Robie alluded to in his introductory post, one of the consequences of the git ubuntu importer is that there is now a standard way to obtain the source of any given source package: git ubuntu clone1.

Getting git ubuntu clone

git-ubuntu is distributed as a “classic” snap. To install it on Ubuntu 16.04 or later:
sudo snap install --classic git-ubuntu. Help is available via git-ubuntu --help and man-pages are currently in development 2.

Using git ubuntu clone

Let’s say we are interested in looking at the state of PHP 7.0 in Ubuntu. First, we obtain a local copy of the repository 3: git ubuntu clone php7.0


With that one command, we now have the entire publishing history for php7.0 in ./php7.0. Anyone who has tried to find the source for an Ubuntu package before will recognize this as a significant simplification and improvement.

With git, we would expect to be on a ‘master’ branch after cloning. git ubuntu clone defaults to a local branch ‘ubuntu/devel’, which represents the current tip of development in Ubuntu. ‘ubuntu/devel’ is branched from the remote-tracking branch ‘pkg/ubuntu/devel’.


You might now be wondering, “What is ‘pkg/’?”

The default remotes

Running git remote, we see two remotes are already defined: ‘pkg’ and ‘nacc’.


‘pkg’ will be the same for all users and is similar to ‘origin’ that git users will be familiar with. The second is a derived remote name based upon a Launchpad ID. As shown above, the first time run git ubuntu runs, it will prompt for a Launchpad ID that will be cached for future use in ~/.gitconfig. Much like ‘origin’, the ‘pkg’ branches will keep moving forward via the importer and running git fetch pkg will keep your local remote-tracking branches up to date. While not strictly enforced by git or git ubuntu, we should treat the ‘pkg/’ namespace as reserved and read-only to avoid any issues.

The importer branches

The tip of ‘pkg/ubuntu/devel’ reflects the latest version of this package in Ubuntu. This will typically correspond to the development release and often will be the version in the ‘-proposed’ pocket for that release. As mentioned earlier, a local branch ‘ubuntu/devel’ is created by default, which starts at ‘pkg/ubuntu/devel’, much like ‘master’ typically starts at ‘origin/master’ by default when using git. Just like the tip of ‘ubuntu/devel’ is the latest version in Ubuntu for a given source package, there are series-‘devel’ branches for the latest in a given series, e.g., the tip of ‘pkg/ubuntu/xenial-devel’ is the latest version uploaded to 16.04. There are also branches tracking each ‘pocket’ of every series, e.g. ‘pkg/ubuntu/xenial-security’ is the latest version uploaded to the security pocket of 16.04.

Finally, there is a distinct set of branches which correspond to the exact same histories, but with quilt patches applied. Going into the reasoning behind this is beyond the scope of this post, but will be covered in a future post. It is sufficient for now to be aware that is what ‘pkg/applied/*’ are for.

What else can we do?

All of these branches have history, like one would expect, reflecting the exact publishing history of php7.0 within the context of that branch’s semantics, e.g., the history of ‘pkg/ubuntu/xenial-security’ shows all uploads to the security pocket of 16.04 and what those uploads, in turn, are based off of, etc. As another example, git log ubuntu/devel shows you the long history of the latest upload to Ubuntu.

With this complete imported history, we can not only see the history of the current version and any given series, but also what is different between versions and releases 16.04 and 17.04 for php7.0!


For other source packages that have existed much longer, you would be able to compare LTS to LTS, and do all the other normal git-ish things you might like, such as git blame to see what introduced a specific change to a file.

We can also see all remote-tracking branches with the normal git branch -r


This shows us a few of the namespaces in use currently:

  • pkg/ubuntu/* — patches-unapplied Ubuntu series branches
  • pkg/debian/* — patches-unapplied Debian series branches
  • pkg/applied/ubuntu/* — patches-applied Ubuntu series branches
  • pkg/applied/debian/* — patches-applied Debian series branches
  • pkg/importer/* — importer-internal branches

As Robie mentioned in the first post, we are currently using a whitelist to constrain the importer to a small subset of source packages. What happens if you request to clone a source package that has not yet been imported?

While many details (particularly why the repository looks the way it does) have been glossed in this post, we now have a starting point for cloning any source package (if it has been imported) and a way to request an import of any source package.

Using git directly (for advanced users)

Technically, git ubuntu clone is equivalent in functionality to git clone and git clone could be used directly. In fact, one of our goals is to not impede a “pure” git usage in any way. But again, as Robie mentioned in his introductory post, there are some caveats to both using git and the structure of our repositories that git ubuntu is aware of. The “well-defined URLs” just mentioned are still being worked on, but for instance for PHP 7.0, one could follow the instructions at the top of the Launchpad code page for the php7.0 source package. The primary differences we would notice in this usage is “origin” instead of “pkg” and there will not be a remote for your personal Launchpad space for this source package.

Conclusion

In this post, we have seen a new way to get the source for any given package, git ubuntu clone.

Robie’s next post will discuss where the imported repositories are and what they look like. My next post will continue discussing the git ubuntu tooling, by looking at another relatively simple subcommand “tag”.


  1. Throughout this post, we are assuming a automatically updated repository. This is true for the whitelisted set of packages currently auto-imported, but not true generally (yet). 
  2. All commands are available as both git-ubuntu … and git ubuntu …. However, for –help to work in the latter form, the changes mentioned in LP : #1699526, a few simple tweaks to ~/.gitconfig are necessary until some additional snap functionality is available generally. 
  3. Currently, git ubuntu clone is rather quiet while it works, and can take a long time (the history of a source package can be long!); we have received feedback and opened a bug to make it a bit more like git clone from a UX perspective. 

usd has been renamed to git-ubuntu

After some internal bikeshedding, we decided to rework the tooling that the Server Team has been working on for git-based source package management. The old tool was usd (Ubuntu Server Dev), as it stemmed from a Canonical Server sprint in Barcelona last year. That name is confusing (acronyms that aren’t obvious are never good) and really the tooling had evolved to be a git wrapper.

So, we renamed everything to be git-ubuntu. Since git is awesome, that means git ubuntu also works as long as git-ubuntu is in your $PATH. The snap (previously usd-nacc) has been deprecated in favor of git-ubuntu (it still exists, but if you try to run, e.g., usd-nacc.usd you are told to install the git-ubuntu snap). To get it, use:

sudo snap install --classic git-ubuntu

We are working on some relatively big changes to the code-base to release next week:

  1. Empty directory support (LP: #1687057). My colleague Robie Basak implemented a workaround for upstream git not being able to represent empty directories.
  2. Standardizing (internal to the code) how the remote(s) work and what refspecs are used to fetch from them.

Along with those architectural changes, one big functional shift is to using git-config to store some metadata about the user (specifically, the Launchpad user name to use, in ~/.gitconfig) and the command used to create the repository (specifically, the source package name, in <dir>/.git/config). I think this actually ends up being quite clean from an end-user perspective, and it means our APIs and commands are easier to use, as we can just lookup this information from git-config when using an existing repository.

As always, the latest code is at: https://git.launchpad.net/usd-importer

[USD #1] Ubuntu Server Dev git Importer

This is the first in a series of posts about the Ubuntu Server Team’s git importer (usd). There is a lot to discuss: why it’s necessary, the algorithm, using the tooling for doing merges, using the tooling for contributing one-off fixes, etc. But for this post, I’m just going to give a quick overview of what’s available and will follow-up in future posts with those details.

The importer was first announced here and then a second announcement was made here. But both those posts are pretty out-of-date now… I have written a relatively current guide to merging which does talk about the tooling here, and much of that content will be re-covered in future blog posts.

The tooling is browse-able here and can be obtained via

git clone https://git.launchpad.net/usd-importer

This will provide a usd command in the local repository’s bin directory. That command resembles git as being the launching point for interacting with imported trees — both for importing them and for using them:

usage: usd [-h] [-P PARENTFILE] [-L PULLFILE]
 build|build-source|clone|import|merge|tag ...

Ubuntu Server Dev git tool

positional arguments:
 build|build-source|clone|import|merge|tag
 
 build - Build a usd-cloned tree with dpkg-buildpackage
 build-source - Build a source package and changes file
 clone - Clone package to a directory
 import - Update a launchpad git tree based upon the state of the Ubuntu and Debian archives
 merge - Given a usd-import'd tree, assist with an Ubuntu merge
 tag - Given a usd-import'd tree, tag a commit respecting DEP14

...

More information is available at https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow.

You can run usd locally without arguments to view the full help.

Imported trees currently live here. This will probably change in the future as we work with the Launchpad team to integrate the functionality. As you can see, we have 411 repositories currently (as of this post) and that’s a consequence of having the importer running automatically. Every 20 minutes or so, the usd-cron script checks if there are any new publishes of source packages listed in usd-cron-packages.txt in Debian or Ubuntu and runs usd import on them, if so.

I think that’s enough for the first post! Just browsing the code and the imported trees is pretty interesting (running gitk on an imported repository gives you a very interesting visual of Ubuntu development). I’ll dig into details in the next post (probably of many).