git ubuntu clone
Canonical
on 9 August 2017
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 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
Ubuntu cloud
Ubuntu offers all the training, software infrastructure, tools, services and support you need for your public and private clouds.
Newsletter signup
Related posts
Canonical announces Ubuntu Security Research Alliance Program
Today, Canonical, the publisher of Ubuntu, announced its new Ubuntu Security Research Alliance Program, a free partnership between Canonical and open source...
Documentation, development and design for technical authors
Typically, a technical writer takes the product created by a development team, and writes the documentation that expresses the product to its users. At...
Join Canonical in Mumbai at HPE Discover More
Canonical, the company behind Ubuntu, is proud to sponsor HPE Discover More in Mumbai. Join us to learn how Canonical and Hewlett Packard Enterprise (HPE) can...