Hi Raphaël, On Thu, Nov 15, 2018 at 03:22:14PM +0100, Raphaël Halimi wrote: > Hi, > > I have a question about gbp. > > I'd like to know if there is any "best practice" workflow for gbp in the > specific case when one is both upstream and debian package maintainer. > > I already asked this question on debian-mentors [1] - although in a > different form - a couple of years ago, but despite a fair number of > answers, I still have problems with my workflow. > > Let's say that I have a project on GitHub. The "master" branch then > conventionally holds the upstream sources. Then I create a > "debian/master" branch to hold a copy of the upstream sources and the > debian packaging files. > > Now, the first problem encountered is with importing upstream tarballs > to the pristine-tar branch. > > Currently, I have to run "uscan" to get the pristine tarball as built by > GitHub) and then run "pristine-tar ../<tarball> master" to import it in > the pristine-tar branch. This is tedious, and error-prone. > > This could be automatically done by "gbp import-orig --uscan", taking > advantage of the branches names already configured in debian/gbp.conf, > but this method has two problems: it complains about the tag already > existing in the Git repository, and it tries to import the sources again > in the upstream branch ("master" here). > > The suggestion in [2] seems neat, but has two problems I'd like to > avoid: the Git repository would be cluttered with two upstream branches, > and two set of tags. > > In your opinion, would it be reasonable/useful (I can't believe I'm the > only person confronted to this problem) to have an option in "gbp > import-orig" to only take care of the upstream tarball, and not update > the upstream branch or add tags, but still use them to link histories > thanks to the "--upstream-tag" and "--upstream-vcs-tag" options ? > > Also, either with my current workflow or if "gbp import-orig" would > provide such an option, there would still be a slight problem : unless I > missed something, "gbp clone" only checks out the three "traditional" > Debian packaging branches (master, upstream, and pristine-tar). For > example, with my current workflow, someone using "gbp clone" on the > GitHub repository would have to notice that the "master" branch lacks a > debian/ directory, and manually checkout the debian/master branch. > > Granted, in that case, "gbp clone" doesn't have a gbp.conf to tell it > the name of the branches it has to checkout, but maybe a simple > heuristic method (for example, "if the master branch lacks a debian/ > directory, look for a branch named debian, or debian/master, or > debian/sid, or any branch name suggested by DEP14, check that its latest > tag matches the latest one on master, and if this branch holds a > debian/gbp.conf file, then read it and checkout the right branches). > > I know that suggesting those changes would be much more polite with > patches attached, but unfortunately, I'm really, really not at ease with > Python. > > Anyway, feel free to tell my what you think about those suggestions, > even if you think they're dumb and/or too marginal to be useful for a > significant number of users.
Are there any reasons why you don't just use master as your upstream branch. Is it because you want the tarball 1:1 comitted to git? If you do use master as your upstream no import is necessary. If you want pristine-tar commits use --git-pristine-tar commit when building or "gbp export-orig / gbp pristine-tar". This also makes "gbp clone" work out of the box. This is what I'm doing for my projects. Also have a look at the (unfinished) "gbp import-ref" in current git. I'm cc'ing the gbp list since this might be of interest to others. Hope this helps, -- Guido > [1] https://lists.debian.org/debian-mentors/2016/04/msg00160.html > [2] https://lists.debian.org/debian-mentors/2016/04/msg00165.html > > Regards, > > -- > Raphaël Halimi > _______________________________________________ git-buildpackage mailing list git-buildpackage@lists.sigxcpu.org http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage