On Oct 21, 2015, at 02:06 PM, Piotr Ożarowski wrote: >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
How about this: """ DPMT requires a pristine-tar branch, and only upstream tarballs can be used to advance the upstream branch. Complete upstream git history should be avoided in the upstream branch. """ I like the cherry picking advice, so I added that to 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 I removed the sentence about gbp. That's a local decision so it doesn't need to go in policy. >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. +1 >> >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. Yep. Again though, since this is a local decision, it should go in the wiki. Cheers, -Barry
