Secure Developments

USE=“experimental-git” sys-apps/portage

drobbins recent tip made me think, that maybe I should point out that his solution to the problem is an annoying work around. I had this problem for a while, it was caused by my having autocrlf = input in my .gitconfig settings. Several people have told me that they have this problem without changing their crlf settings for git. After a while I decided that Funtoo/Gentoo’s git handling patches were incomplete at best and unfriendly at worst. So I wrote a patch that brings complete git handling to portage.

Why is it experimental? well it hasn’t been officially accepted into portage, and as far as I know I’m the only one using it. One of the reason’s it’s not officially accepted is I haven’t documented it.

WARNING: enabling it will cause auto git detection to fail, so if you don’t finish setting it up portage will default to rsync.

So first you need to be using my regen2 tree, or get the ebuild and the patch from my tree, and enable the experimental-git flag for sys-apps/portage.

Now, like all the other protocols portage supports you need to set the SYNC variable in /etc/make.conf.


the first 6 characters need to be git:// for git to work.

if you don’t already have a git repository then sync will clone the repository at this url, in fact you may need to delete your portage and do a fresh clone for things to work in certain situations. I never discerned the reason for this.

now you need to set your method the most reliable, yet slowest is checkout.


I believe this method will never experience the problem that drobbins was referring to.

for checkout you also need to set the remote branch you want to run off.

PORTAGE_GIT_REMOTE=“origin/” changing this variable and resyncing will allow you to change branches. checkout is even immune to upstreams forced updates, which is why I prefer to use it myself as sometimes I force updates on my development branch.

PORTAGE_GIT_LOCAL=“” is also a valid variable, however checkout doesn’t use it. It’s used by the methods rebase, which will run the git rebase command, this is recommended for people who don’t run their own remote repo yet have there own custom git patches.

The final method available is merge, it works similar to the current pull behavior of portage, except it will actually merge from whatever remote you have specified into whatever local you have specified.

all methods use git remote update to avoid problems figuring out where to get updates from. I had problems with git knowing what to do with pull, when my origin was my personal repo on github and where I really needed to be updating from was funtoo not origin.

WARNING: git-experimental will probably be where I merge patches such as the upcoming manifest patch.


comments powered by Disqus