Gentoo git workflow

From Gentoo Wiki
Jump to: navigation, search

This article outlines some rules and best-practices regarding the typical workflow for ebuild developers using git.

Commit policy

  • 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 -> CATEGORY/PN:
    • Profile directory -> profiles:
    • Eclass directory -> ECLASSNAME.eclass:
    • Licenses directory -> licenses:
    • Metadata directory -> metadata:
    • A whole category -> CATEGORY:
  • 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 Acked-by:, 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 <>
Reported-by: Alice Wonderland <>

Branching model

  • 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: dev/<name>
  • Project branches: project/<name>
  • If in doubt, or if the branch could be useful to others, discuss the naming on-list beforehand.

About rebasing

  • Primary use case: in case of a non-fast-forward push conflict to remote master, try git pull --rebase=preserve first; 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.

About merging

  • Do not ever commit implicit merges done by git pull. You may want to set git config --local pull.ff only to 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 --no-ff).
  • 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.

Remote model

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 merges stuff into user sync repository and updates the metadata cache there.

User sync repository is for power users than 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 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.

Best practices

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

Repository settings


Clone the repository. This will make a shallow clone and speed up clone time:

user $git clone --depth=50 git+ssh://
You need at least git-1.9 for shallow clones to work properly, so that you can also push back to the remote dev repository.

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:

First, 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).

user $gpg --list-public-keys --keyid-format 0xlong

Now write the actual config.

user $cd gentoo
user $git config --local "Your Full Name"
user $git config --local ""
user $git config --local user.signingkey 0xLONG-GPG-KEY
user $git config --local commit.gpgsign 1
user $git config --local pull.ff only
user $git config --local pull.rebase preserve
user $git config --local push.default simple
user $git config --local push.gpgsign 1

In addition, you need to tell repoman which key to use, in case repoman is used for committing:

FILE /etc/portage/make.conf

Workflow walkthrough

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.

user $git status

Common ebuild work

  1. Pull in the latest changeset, before starting your work:
    user $git pull --rebase=preserve origin master
  2. Do the work (including removing files)
  3. Make sure you are in the ebuild directory
  4. Create the manifest:
    user $repoman manifest
  5. Stage files (including removed ones), if any:
    user $git add <new-files> <changed-files> <removed-files>
    A shortcut for staging all files in the current dir (and subdirs) would be:
    user $git add -- .
  6. Check for errors:
    user $repoman full
    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:
    user $git status
    To clean up unstaged changes and untracked files run:
    user $git checkout -- .
    user $git clean -i
    1. If errors occur, fix them and continue from point 4
  7. Commit the files:
    user $repoman commit
    and enter your meaningful commit message
  8. Push to the dev repository:
    user $git push --signed origin master
    1. If updates were rejected because of non-fast-forward push, try:
      user $git pull --rebase=preserve -S"$(git config --get user.signingkey)" origin master
      first, then run:
      user $repoman full
      and continue from point 8.
      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:
      user $git diff $(git merge-base master remotes/origin/master) remotes/origin/master
      1. 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:
        user $git mergetool
        user $git rebase --continue
        and continue from point 4
      2. If the rebase fails and the conflicts are complicated or you think the information is useful, continue with a regular merge:
        user $git rebase --abort
        user $git merge remotes/origin/master
        1. If merge conflicts occur, fix them via:
          user $git mergetool
          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.
        2. If no merge conflicts occur, run:
          user $repoman full
          and continue from point 8 above.

Pull requests from developers and users

git am method

  1. Find a pull request you wish to merge, as an example.
  2. Ensure your checkout is up to date:
    user $git pull
  3. Fetch and apply chosen commit:
    user $curl -s -L "" | git am -s -S
  4. You can review the changes with:
    user $git log remotes/origin/master..HEAD
    user $git diff remotes/origin/master..HEAD
  5. Make sure chosen commit didn't break things
    user $repoman -d full
    repoman will not pickup outdated copyright year in the header
  6. Push your changes
    user $git push --signed

git cherry-pick method

  1. Identify the remote URL and the branch to be merged.
  2. Add a new remote:
    user $git remote add <remote-name> <url>
  3. Fetch the changes:
    user $git fetch <remote-name> <branch>
  4. You may review the changes manually first:
    user $git log master..remotes/<remote-name>/<branch>
    user $git diff master..remotes/<remote-name>/<branch>
  5. Checkout the remote branch:
    user $git checkout remotes/<remote-name>/<branch>
    (you are now in detached HEAD mode)
  6. Test the ebuilds and run repoman:
    user $repoman full
  7. If everything is fine, switch back to master:
    user $git checkout master
  8. Ensure your master branch is curent:
    user $git pull
  9. If it's just one commit, do:
    user $git cherry-pick <commit-hash>
  10. If there are multiple commits in one consistent range, do:
    user $git cherry-pick <first-new-commit-hash>^..<latest-new-commit-hash>
  11. Push your changes
    user $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>.


repoman: "Malformed CVS Header" warning

The former # $Header: $ header is no more and has been substituted with a # $Id$ header during the migration. Hence, you'll often run into this warning:

user $$ repoman full -d

RepoMan scours the neighborhood...

>>> Creating Manifest for /home/user/gentoo/dev-java/rhino

 ebuild.badheader              3
   dev-java/rhino/rhino-1.6.5.ebuild: Malformed CVS Header on line: 3
   dev-java/rhino/rhino-1.7.2-r2.ebuild: Malformed CVS Header on line: 3
   dev-java/rhino/rhino-1.7.7.ebuild: Malformed CVS Header on line: 3

For the time being, you can safely ignore it and go ahead with your changes. A patch has already been sent out and discussed on the portage-dev mailing list to match the new header and silence this warning. See the full discussion.

This problem is fixed since sys-apps/portage- If you still see this, you might need to update portage.

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:

user $$ 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:

user $$ 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:

  1. make sure the directory has the correct access rights
  2. 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 =
  fetch = +refs/heads/*:refs/remotes/github/*
  fetch = +refs/pull/*/head:refs/remotes/github/pr/*

Now type:

user $$ git fetch github

git should go and fetch all pull requests, and list them as branches.

user $$ 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, simply type:

user $$ 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:

user $$ git fetch history
user $$ git replace --graft 56bd759df1d0c750a065b8c845e93d5dfa6b549d history/master

The general syntax of the last command is:

user $$ 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.

user $cd .git/refs/packs
user $ls -lh
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:

user $touch pack-05c10cc8ef170fd182619ef32ec4007e5f32f46d.keep pack-412c2dda845a79854872afaf5f9cd4ea896aef38.keep

Retaining commit author information

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:

user $git log --format=fuller

If necessary, amend the commit to give credit where it is due:

user $git commit --amend --author="Joe Smith <>"

See also

External resources

And summarizing it all, ...