If the Git™ repository wasn't created with gbp import-dsc, you have to tell gbp buildpackage and friends where to find the upstream sources.
If the upstream sources are already on a separate branch, things are pretty
simple. You can either rename that branch to the default
upstream-branch name upstream with:
git branch -m theupstream-branch upstream
or you can tell gbp buildpackage the name of the branch to use as
cat <<EOF >
.git/gbp.conf[DEFAULT] # this is the upstream-branch: upstream-branch=theupstream-branch EOF
If you then use gbp import-orig to import new upstream sources, they will
from now on end up on theupstream-branch and
merged to the
If you don't have an upstream branch but started your repository with only the upstream sources (not the Debian™ patch), you can simply branch from that point. So use gitk or git-log to locate the commit-id of that commit and create the upstream branch from there, e.g.:
git branch upstream $(git log --format='%H' | tail -1)
The important thing here is that the
COMMIT_ID specifies a
point on the master branch that carried only the
upstream sources and not the Debian™ modifications. The above example
assumes that this was the first commit to that repository.
There's currently no easy way to create the
upstream-branch if you never had the upstream sources
as a single commit. Using gbp import-orig on such repositories might lead
to unexpected merge results.
In order to fix this you can prepend the upstream sources as a single commit to your tree using Git™'s grafts. Afterwards you can simply create a branch as explained above and gbp import-orig will work as expected.
Alternatively, if you are only importing source from original tarballs (for instance when converting from a Subversion repository where the mergeWithUpstream was set for svn-buildpackage), you can create an empty upstream branch with the following commands:
'Initial upstream branch.'git checkout
master# When not using 3.0 (quilt) with the default --merge-mode=auto git merge