What else can we do?Īll 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. It is sufficient for now to be aware that is what ‘pkg/applied/*’ are for. ![]() Going into the reasoning behind this is beyond the scope of this post, but will be covered in a future post. ‘pkg/ubuntu/xenial-security’ is the latest version uploaded to the security pocket of 16.04.įinally, there is a distinct set of branches which correspond to the exact same histories, but with quilt patches applied. ![]() ![]() There are also branches tracking each ‘pocket’ of every series, e.g. 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. 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. This will typically correspond to the development release and often will be the version in the ‘-proposed’ pocket for that release. The tip of ‘pkg/ubuntu/devel’ reflects the latest version of this package in Ubuntu. While not strictly enforced by git or git ubuntu, we should treat the ‘pkg/’ namespace as reserved and read-only to avoid any issues. 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. 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. The second is a derived remote name based upon a Launchpad ID. ‘pkg’ will be the same for all users and is similar to ‘origin’ that git users will be familiar with. First, we obtain a local copy of the repository***: git ubuntu clone php7.0 Let’s say we are interested in looking at the state of PHP 7.0 in Ubuntu. Help is available via git-ubuntu -help and man-pages are currently in development** Using git ubuntu clone To install it on Ubuntu 16.04 or later: sudo snap install -classic git-ubuntu. Git-ubuntu is distributed as a “classic” snap. 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 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?”. In this post, we will introduce the git ubuntu clonesubcommand and take a brief tour of what an imported repository looks like. ![]() As mentioned there, it is important to keep in mind that the tooling and implementation are still highly experimental. There is an index of all our planned posts in the first post. This is the second post in a collaborative series between Robie Basak and myself to introduce (more formally) git ubuntuto a broader audience.
0 Comments
Leave a Reply. |