git ubuntu clone

This is the second post in a collaborative series between Robie Basak and myself to introduce (more formally) git ubuntuto 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 clonesubcommand 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 clone*

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**

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***: 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”.

*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).

**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|https://bugs.launchpad.net/usd-importer/+bug/1699526], a few simple tweaks to ~/.gitconfig are necessary until some additional snap functionality is available generally.

***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|https://bugs.launchpad.net/usd-importer/+bug/1707225] to make it a bit more like git clone from a UX perspective.

This blogpost originated from Nish’s Blog