[Barry Warsaw, 2015-10-21] > What I'm trying to express is the team decision (a couple of debconfs ago) for > pristine-tars rather than releasing from upstream git. I do want to keep the > rationale in the policy doc; it's one sentence and it seems to come up often > enough. Suggestions for better phrasing welcome!
Only version to version upstream changes should be kept in the repository - complete upstream git history should be avoided. In order to make it easier to cherry-pick upstream commits as patches, add remote repository (example below). git remote add upstream_repo git://example.com/foo.git git fetch upstream_repo git-dpm checkout-patched git cherry-pick any_upstream_commit git-dpm update-patches > >> +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package > >> directory. > > > >gbp can use sbuild/pbuilder, here's my ~/.gbp.conf: > > > > [buildpackage] > > builder=sbuild > > This is the kind of thing that should go in the wiki. > I simply suggest to: s/, either as a source package for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory/ (it can be configured to use sbuild, pbuilder, etc.)/ or remove this part completely > >> +Use the following ``git-dpm`` tag formats for the three branches named > >> above. > >> +Put these lines at the *end* of your ``debian/.git-dpm`` file:: > >> + > >> + debianTag="debian/%e%v" > >> + patchedTag="patches/%e%v" > >> + upstreamTag="upstream/%e%u" > > > >I will update `py2dsp --profile dpmt ...` to do that out of the box, but > >even then, it's better to suggest that tool in the wiki only, I guess > > I think so. The tag format (and IMHO the mechanism to ensure it) should go in > policy though. nothing against this paragraph, just wanted to state that wiki will not have to mention it if we have a tool that configures new package the way policy wants. > >I'm wondering about something that bit me recently: `gbp pull` instead > >of `git pull` - should we put that into policy or is wiki warning enough? > > I think wiki is enough. It is possible to operate with just straight `git > pull` because it will still fetch all commits, but when you switch to one of > the other branches, you'll see that its head is out of date, and git will > prompt you to pull in that branch to update it. `gbp pull` is mostly > convenience. gbp buildpackage will fail if you never switched to pristine-tar (and git didn't warn you about new commits). It wasn't obvious to me why it fails when it hit me for the first time. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
