Gentoo git workflow
This article is not maintained by Gentoo developers. Some of the policies and suggestions listed here may be plain wrong. If in doubt, please refer to the official standard of GLEP 66.
This article outlines some rules and best-practices regarding the typical workflow for ebuild developers using git.
- 1 Commit policy
- 2 Branching model
- 3 Remote model
- 4 Best practices
- 5 Repository settings
- 6 Workflow walkthrough
- 7 Tips and tricks
- 7.1 Working with git
- 7.2 Diffs for revision bumps
- 7.3 Using the gentoo git checkout as your local tree
- 7.4 Github pull request made easy
- 7.5 Grafting Gentoo history onto the active repository
- 7.6 Preventing 'git repack -a' from touching huge packs
- 7.7 Retaining commit author information
- 7.8 A cli-tool to crawl through pull requests
- 8 See also
- 9 External resources
- 10 And summarizing it all, ...
- Atomic commits (one logical change).
- All commits must be repoman-valid (exceptions only on right-hand branches).
- Commits may span across multiple ebuilds/directories if it's one logical change.
- Every commit on the left-most line of the history (that is, all the commits following the first parent of each commit) must be GPG signed by a Gentoo developer.
- repoman must be run from all related ebuild directories (or related category directories or top-level directory) on the tip of the local master branch (as in: right before you push and also after resolving push-conflicts).
- Commits in git are cheap and local, so use them often.
- Split version bumps and ebuild cleanup in separate commits (makes reverting ebuild removals much easier).
- One may break atomicity in order to make a commit repoman-valid (or you should reconsider the order you commit in, e.g. license first, then the new ebuild).
Commit message format
- All lines max 75 characters.
- If CATEGORY/PN is very long and 75 character limit is impossible to obey it is OK to exceed the limit in this case.
- First line brief explanation.
- Second line always empty.
- Optional detailed multiline explanation must start at the third line.
- Commits that affect primarily a particular subsystem should prepend the following code to the first line of the commit message:
- Single package ->
- Profile directory ->
- Eclass directory ->
- Licenses directory ->
- Metadata directory ->
- A whole category ->
- Single package ->
- If the change affects multiple directories, but is mostly related to a particular subsystem, then prepend the subsystem which best reflects the intention (e.g. you add a new license, but also modify profiles/license_groups).
- It is also encouraged to use tag formats such as
Suggested-by:, and so on. Please review the kernel patch guideline for additional tag variants.
app-misc/foo: version bump to 0.5 Bump to 0.5. This also fixes security bug 93829 and introduces the new USE flag 'bar'. Acked-by: Hans Wurst <firstname.lastname@example.org> Reported-by: Alice Wonderland <email@example.com>
- The primary production-ready branch is master (users will pull from here), there are only fast-forward pushes allowed.
- There may be developer-specific, task-specific, project-specific branches, etc.
Branch naming convention
- Developer branches:
- Project branches:
- If in doubt, or if the branch could be useful to others, discuss the naming on-list beforehand.
- Primary use case: in case of a non-fast-forward push conflict to remote master, try
git pull --rebase=preservefirst; if that yields complicated conflicts, abort the rebase and continue with a regular merge (if the conflicts are trivial or even expected, e.g. arch teams keywording/stabilizing stuff, then stick to the rebase).
- To preserve merges during a rebase use
git rebase --preserve-merges ...(if appropriate, e.g. for user branches).
- Don't use --preserve-merges if you do an interactive rebase (see BUGS in git-rebase manpage).
- Commits that are not on the remote master branch yet may be rewritten/squashed/splitted etc via interactive rebase, however the rebase must never span beyond those commits.
- Never rebase on already pushed commits.
- There are no particular rules for rebasing on non-master remote branches, but be aware that others might base their work on them.
- There are no particular rules for rebasing non-remote branches, as long as they don't clutter the history when merged back into master.
- Don't do complicated rebases to avoid a merge commit at all cost.
- Do not ever commit implicit merges done by git pull. You may want to set
git config --local pull.ff onlyto avoid git implicitly creating those.
- If a rebase fails or is too complicated, do a regular merge instead.
- Do a merge if the information is useful (e.g. pulled from a foreign remote user branch or merged a non-trivial eclass conversion back into master) and force a merge commit (non-fast-forward merge via
- To avoid a merge commit when merging local branches back to master (e.g. information is not useful), you may try to force a fast-forward merge by first rebasing the local branch against master and then merging it into master, see here.
- Extend merge commit messages with useful information, e.g. how conflicts were solved.
- Keep in mind that all commits of the first parent of the history must be GPG signed by a Gentoo developer, so you may want to force merge commits especially for user branches.
We have a main developer repository where developers work and commit (every Gentoo ebuild developer has direct push access). For every push into the repository, automated magic things merge stuff into user sync repository and update the metadata cache there.
User sync repository is for power users that want to fetch via git. It's quite fast and efficient for frequent updates, and also saves space by being free of the ChangeLog files.
On top of the user sync repository, rsync is propagated. The rsync tree is populated with all old ChangeLogs copied from CVS (stored in 30 MB git repo); new ChangeLogs are generated from git logs and Manifests are expanded.
- Before starting work on your local master, it's good to pull the latest changeset from the remote master.
- It might be a good idea for projects/developers to accumulate changes either in their own branch or a separate repository and only push to remote master in intervals (that decreases the push rate and potential conflicts).
Clone the repository. This will make a shallow clone and speed up clone time:
git clone --depth=50 git+ssh://firstname.lastname@example.org/repo/gentoo.git
Using the git+ssh:// protocol of cause requires the user's SSH public key on the server.
If you want the full history, just omit
--depth=50 from the above command.
All developers should at least have the following configuration settings in their local developer repository. These setting will be written to .git/config and can also be edited manually. Run these from within the repository you've just cloned in the step above:
git config --local user.name "Your Full Name"
git config --local user.email "email@example.com"
git config --local pull.ff only
git config --local pull.rebase merges
git config --local push.default simple
To get your GPG key run this command. It should be the top line (starting with pub). If you have more than one key with the UID you will need to select the correct key yourself (from the list of returned keys).
gpg --list-public-keys --keyid-format 0xlong firstname.lastname@example.org
git config --local user.signingkey 0xLONG-GPG-KEY
git config --local commit.gpgsign 1
git config --local push.gpgsign 1
In addition, you need to tell repoman which key to use for committing:
These are just examples and people may choose different local workflows (especially in terms of when to stage/commit) as long as the end result works and is repoman-checked. These examples try to be very safe, but basic.
Before doing anything, make sure your git tree is in a correct state and you are in the branch you actually want to work on.
Common ebuild work
- Pull in the latest changeset, before starting your work:
git pull --rebase=preserve origin master
- Do the work (including removing files)
- Make sure you are in the ebuild directory
- Create the manifest:
- Stage files (including removed ones), if any:
git add <new-files> <changed-files> <removed-files>Note
A shortcut for staging all files in the current dir (and subdirs) would be:
git add -- .
- Check for errors:
repoman full -d -xWarning
Repoman checks the files on filesystem level and doesn't really know what changes are staged or committed! So make sure the ebuild directory is clean and there are no unstaged changes or untracked files when running repoman. To check for such changes/files, run:To clean up unstaged changes and untracked files run:
git checkout -- .
git clean -i
- If errors occur, fix them and continue from point 4
- Commit the files: and enter your meaningful commit message
- Push to the dev repository:
git push --signed origin master
- If updates were rejected because of non-fast-forward push, try: first, then run:
git pull --rebase=preserve -S"$(git config --get user.signingkey)" origin masterand continue from point 8.
repoman full -d -xNote
You may skip running repoman another time if you have manually verified that the commits you are missing are totally unrelated to your work (e.g. only affect a package that is not in the dependency chain of yours). You can do so via:
git diff $(git merge-base master remotes/origin/master) remotes/origin/master
- If the rebase fails, but the conflicts are trivial and don't contain useful information (such as keyword stabilization), fix the conflicts and finish the rebase via: and continue from point 4
git rebase --continue
- If the rebase fails and the conflicts are complicated or you think the information is useful, continue with a regular merge:
git rebase --abort
git merge remotes/origin/master
- If merge conflicts occur, fix them via: and continue from point 4
A merge conflict is not to be taken lightly. It could indicate miscommunication in one way or another (e.g. several people working on the same ebuild), so fix that first and try to clarify the situation.
- If no merge conflicts occur, run: and continue from point 8 above.
repoman full -d -x
- If merge conflicts occur, fix them via:
- If the rebase fails, but the conflicts are trivial and don't contain useful information (such as keyword stabilization), fix the conflicts and finish the rebase via:
- If updates were rejected because of non-fast-forward push, try:
Pull requests from developers and users
pram is a tool to help merge pull requests easily.
- Open the pull request assigned for you, or whatever you want to work on. We use https://github.com/gentoo/gentoo/pull/12345 as an example.
- Make sure that everything is done correctly and that every commit has proper sign-off included.
- Apply and automatically close the pull request to ::gentoo repo via
You should always run
pkgcheck scan --commits
pram can be used to merge PRs made to other repo than gentoo/gentoo/. Check it's homepage or manpage for more info.
git am method
- Find a pull request you wish to merge, https://github.com/gentoo/gentoo/pull/1 as an example.
- Ensure your checkout is up to date:
- Fetch and apply chosen commit:
curl -s -L "https://github.com/gentoo/gentoo/pull/1.patch" | git am -sS
- You can review the changes with:
git log remotes/origin/master..HEAD
git diff remotes/origin/master..HEAD
- Make sure chosen commit didn't break things
repoman -d fullImportant
repoman will not pickup outdated copyright year in the header
- Push your changes
git push --signed
git cherry-pick method
- Identify the remote URL and the branch to be merged.
- Add a new remote:
git remote add <remote-name> <url>
- Fetch the changes:
git fetch <remote-name> <branch>
- You may review the changes manually first:
git log master..remotes/<remote-name>/<branch>
git diff master..remotes/<remote-name>/<branch>
- Checkout the remote branch: (you are now in detached HEAD mode)
git checkout remotes/<remote-name>/<branch>
- Test the ebuilds and run repoman:
- If everything is fine, switch back to master:
git checkout master
- Ensure your master branch is curent:
- If it's just one commit, do:
git cherry-pick <commit-hash>
- If there are multiple commits in one consistent range, do:
git cherry-pick <first-new-commit-hash>^..<latest-new-commit-hash>
- Push your changes
git push --signed
Alternatively, you can create a new local branch where you pull in the remote changes instead of working directly in detached HEAD mode on remotes/<remote-name>/<branch>.
Tips and tricks
Working with git
Especially staging files can be tedious on the CLI. So you may want to use the graphical clients gitk (for browsing history) and git gui (for staging/unstaging changes etc.). You have to enable the
tk USE flag for dev-vcs/git.
Diffs for revision bumps
Suppose you are making a new revision of the
app-foo/bar package—you are removing
app-foo/bar-1.0.0 and replacing it with the new revision
app-foo/bar-1.0.0-r1. In that case, git (by default) sees two changes: removal of the file
bar-1.0.0.ebuild and addition of the file
bar-1.0.0-r1.ebuild. If you attempt to view your changes with
git diff or
git show, you'll get a useless diff containing the entirety of both files.
Git can be coerced into showing you the diff between the old and new revisions even though they live in separate files. The following command-line options specify how hard git should try to find files that have been copied or renamed:
$ git diff --find-renames --find-copies --find-copies-harder
In the common case, searching for renames is enough. You can make that behavior the default easily:
$ git config --local diff.renames true
Using the gentoo git checkout as your local tree
If you want to use your git development checkout as your local tree, you have to do two things:
- make sure the directory has the correct access rights
- generate/get metadata-cache, dtd, glsa, herds.xml and news yourself
For the latter, there are example hooks for portage and paludis. You should probably skip the files /etc/portage/repos.conf/gentoo.conf and /etc/paludis/repositories/gentoo.conf respectively, so that portage/paludis doesn't mess up your checkout (as in: disable auto-sync).
The linked hooks are WIP and may be subject to change!
Github pull request made easy
Cd into your gentoo Git repository and add these lines to the repo's .git/config file:
[remote "github"] url = email@example.com:gentoo/gentoo.git fetch = +refs/heads/*:refs/remotes/github/* fetch = +refs/pull/*/head:refs/remotes/github/pr/*
$ git fetch github
git should go and fetch all pull requests, and list them as branches.
$ git branch -a
Each pull request will now be displayed as a branch name, each with a different name such as "remotes/github/pr/123". For instance if you wish to fetch changes brought by https://github.com/gentoo/gentoo/pull/105, simply type:
$ git checkout remotes/github/pr/105
to checkout the pull request.
Grafting Gentoo history onto the active repository
To graft the historical Gentoo repository onto your current one simply run:
$ git remote add history https://github.com/gentoo/gentoo-gitmig-20150809-draft.git
$ git fetch history
$ git replace --graft 56bd759df1d0c750a065b8c845e93d5dfa6b549d history/master
The general syntax of the last command is:
$ git replace --graft <first new commit> <last old commit>
(This may be useful if you're not using the official versions of the repositories.)
Once you've merged the history, git will behave as if it is one big repo, and you should still be able to push from that to Gentoo as the head is untouched. Merging the history will remove the gpg signature on the initial gentoo commit (since it is being modified to do the graft).
Preventing 'git repack -a' from touching huge packs
Normally git repack -a (invoked by git gc) tries to repack everything into a single pack. If your repository contains a few huge packs already (commits from initial clone, grafted history pack), the repack can take really long and be truly memory-consuming.
To avoid that, you can mark the huge pack files for keeping. In this case, git repack -a won't touch those packs and instead focus on repacking everything else. As a result, you can get most of the benefits of repacking with major time saving.
total 2.2G -r--r--r-- 1 mgorny mgorny 17M Oct 3 16:14 pack-05c10cc8ef170fd182619ef32ec4007e5f32f46d.idx -r--r--r-- 1 mgorny mgorny 219M Oct 5 16:12 pack-05c10cc8ef170fd182619ef32ec4007e5f32f46d.pack -r--r--r-- 1 mgorny mgorny 27K Oct 5 14:09 pack-107a6ca6e4b781d12cc452a651a478daac3b3d95.idx -r--r--r-- 1 mgorny mgorny 978K Oct 5 16:12 pack-107a6ca6e4b781d12cc452a651a478daac3b3d95.pack -r--r--r-- 1 mgorny mgorny 25K Oct 6 08:14 pack-10f2b4a18cd1a99dcbc502987eb130680221b558.idx -r--r--r-- 1 mgorny mgorny 770K Oct 6 08:14 pack-10f2b4a18cd1a99dcbc502987eb130680221b558.pack -r--r--r-- 1 mgorny mgorny 197M Oct 3 18:06 pack-412c2dda845a79854872afaf5f9cd4ea896aef38.idx -r--r--r-- 1 mgorny mgorny 1.7G Oct 3 18:05 pack-412c2dda845a79854872afaf5f9cd4ea896aef38.pack -r--r--r-- 1 mgorny mgorny 5.1K Oct 5 15:38 pack-460c1a0fc0e6fc76d367e2b4010c879ce9b062e2.idx -r--r--r-- 1 mgorny mgorny 187K Oct 5 16:12 pack-460c1a0fc0e6fc76d367e2b4010c879ce9b062e2.pack -r--r--r-- 1 mgorny mgorny 1.4M Oct 6 08:49 pack-5a593371028f920159f628208955707a9153962a.idx -r--r--r-- 1 mgorny mgorny 24M Oct 6 08:49 pack-5a593371028f920159f628208955707a9153962a.pack -r--r--r-- 1 mgorny mgorny 14K Oct 4 08:41 pack-c90e9378fa114d9a603c3ea40c4ff76e2d4cbac6.idx -r--r--r-- 1 mgorny mgorny 401K Oct 5 16:12 pack-c90e9378fa114d9a603c3ea40c4ff76e2d4cbac6.pack
Once you identify the huge packs you'd like to keep (05c10cc8ef170fd182619ef32ec4007e5f32f46d and 412c2dda845a79854872afaf5f9cd4ea896aef38 in this case), create .keep files for them:
touch pack-05c10cc8ef170fd182619ef32ec4007e5f32f46d.keep pack-412c2dda845a79854872afaf5f9cd4ea896aef38.keep
It is important that appropriate credit is given when committing on behalf of others. Git can natively differentiate between who authored a commit and who pushed it (example), and most methods of merging handle this automatically.
If you have applied someone else's changes manually or made local edits to a PR, check that the author field is accurate:
git log --format=fuller
If necessary, amend the commit to give credit where it is due:
git commit --amend --author="Joe Smith <firstname.lastname@example.org>"
If you need to credit several authors, add trailer lines like
Co-authored-by: Name Surname <email@example.com> (as currently supported by major Git hostings like GitHub and GitLab) to the long commit description part:
app-misc/foo: version bump to 0.5 Bump to 0.5. This also fixes security bug 93829 and introduces the new USE flag 'bar'. Co-authored-by: Jane Doe <firstname.lastname@example.org> Acked-by: Hans Wurst <email@example.com> Reported-by: Alice Wonderland <firstname.lastname@example.org>
A cli-tool to crawl through pull requests
gengee is a tool that makes queries through gentoo/gentoo/ pull requests. It can show "outdated" pull requests, ie where a newer version is added to ::gentoo tree, where a linked bug is already closed, or where package in question has been removed from ::gentoo. You can use it to query pull requests assigned to certain maintainers, or opened by certain authors.
gengee-query -m email@example.com
gengee-query -a juippis
gengee-query -l "need assignment"
and so much more.
Check the homepage for an ebuild, info on how to set it up and documentation on how to use it.
- Git — distributed revision control and source code management software.
- gentoo gitweb
- gentoo github mirror
- https://github.com/gentoo-mirror/gentoo - Gentoo repository on Gentoo repository mirrors