[Pkg-protobuf-devel] Git workflow

Robert Edmonds edmonds at debian.org
Fri Nov 6 18:48:30 UTC 2015


Iustin Pop wrote:
> Looking at the git history, it looks like we do keep (and update) some
> things which are expected normally in a tar.gz (e.g. Makefile.in), but
> which upstream doesn't store in git; maybe Robert has some special steps
> done when importing upstream sources?

Hi,

The 'upstream' branch is a combination of upstream's release tarballs
and upstream's repository history, using the --upstream-vcs-tag option
to gbp import-orig.

See:

    http://www.eyrie.org/~eagle/journal/2013-04/001.html

    http://blog.mycre.ws/articles/converting-to-upstream-vcs-tag/

If we don't want to continue basing the Debian .orig.tar.gz on
upstream's release tarballs (or the --upstream-vcs-tag workflow is just
too confusing), then maybe we should switch to a Git-only workflow
(though probably with gbp buildpackage --git-pristine-tar
--git-pristine-tar-commit as a backstop so that we track the
.orig.tar.gz's that we generate).

I must admit to being very confused at the new upstream convention of
producing multiple tarball artifacts from the same repository.  Should
we split src:protobuf into src:protobuf-cpp, src:protobuf-java,
src:protobuf-python, etc. to match upstream's tarballs, or should we
continue to have a single src:protobuf that matches upstream's Git
repository?  I dunno.

Andrew, if you want to start a new repository from scratch and focus on
the packaging details rather than the Git workflow, and figure out what
to do with the old repository history later, that'd be fine with me.

-- 
Robert Edmonds
edmonds at debian.org



More information about the Pkg-protobuf-devel mailing list