Hi, On 02/09/15 12:39, Dmitry Smirnov wrote:
>> If upstream does not tag their releases, you will need to find the >> commit manually and tag it (if you want to keep git history in sync). > > Sorry, I'm not quite sure how exactly can I do that... You mean I should > configure a remote (git remote add github https://github.com/repo/repo) then > > git fetch github > git rebase github/master > > then what? Merge to "upstream" branch and tag there manually? My usual setup and workflow is like this: * My debian packaging branch is called debian/sid (following DEP-14 convention) * I have a remote for the upstream repo. * I have a branch that just follows that repo: $ git fetch github $ git checkout -b upstream github/master * When I want to upgrade the debian package, I just merge changes: $ git fetch github $ git checkout debian/sid $ git merge github/<tag> (if upstream tags releases) $ git merge upstream (if not) $ git tag upstream/<tag> upstream (if there is no tag, I create it manually) * If upstream does not provide tags/tarballs, I tag the version and then generate a tarball from it, using a snippet I include in debian/rules (see many of the packages I uploaded to pkg-go) * With or without upstream tarball, I use pristine-tar to include it in git: $ pristine-tar commit <tarball> >> Otherwise you can just use gbp import-orig and ignore upstream's git >> history, but I prefer the other approach when possible. > > I couldn't care less about upstream history and actually for the sake of > importing mock-up tarball I want to entirely ignore upstream history. > > But how can I do "gbp import-orig" without tarball? I think you are mixing two things here: upstream tags and upstream tarballs. You can live without tags, but not without tarballs! If there is no upstream tarball, you need to create it yourself, for example, like I mentioned before. If upstream does not provide tarballs, I would recommend following their history even more, all the process is simpler. There is a very well documented and tidy process for doing all this, although it is probably way too complicated for most people. Still, it is a good read to have an idea of how to do things: http://blog.mycre.ws/articles/git-packaging-workflow-for-py-lmdb/ Another read: DEP-14, which documents some best-practices for debian/git packaging: http://dep.debian.net/deps/dep14/ -- Martín Ferrari (Tincho) _______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
