Re: DPMT Policy
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
Reply to: