On Feb 11, 2016, at 09:09 AM, Ross Gammon wrote:
>I was working last night on fixing the RC bug for tweepy, but got myself
>in a muddle with git-dpm.
Yep, git-dpm will do this some times. :/
>Tweepy is currently 3.4.0 & 3.5.0 is a new available release. I cloned,
>fixed the bug (just disabling the unit test), confirmed it was fixed and
>then looked at packaging 3.5.0 as a team upload. But git-dpm seemed to
>be unaware of 3.4.0 (claiming that 3.1.0 was the right tarball), that
>there were non-debian changes in the debian branch and wouldn't let me
>import 3.5.0. So I gave up on 3.5.0, and started trying to work out what
>was wrong with 3.4.0 in git-dpm.
Occasionally I find it necessary to blow away a clone and start over, but even
then, git-dpm sometimes does mysterious things. (This is one of several
reasons I'm beginning to sour on it, though it works just fine in the majority
of cases.)
One thing I've found is that import-new-upstream will sometimes not record the
pristine-tar, even if you use --ptc. It seems like this can happen if you
also --rebase and are required to resolve some conflicts. After finally
git-dpm u-p'ing the pristine-tar will not have been recorded. Though you have
to remember to do it, it's easy enough to pristine-tar commit the new
orig.tar.gz after the fact.
The main thing is that when you update to a new upstream, be sure to git-dpm
status (and/or prepare) to be sure everything's okay before you start to work
on further changes on top of the new upstream.
Another gotcha is that if you `git clone` the repo, you won't actually have a
pristine-tar or upstream tracking branch, and this will break git-dpm. Much
better to use `gbp clone` which does the clone and then assures you have the
local tracking branches. If you do git clone, just be sure to checkout the
pristine-tar branch before you start working on things (and upstream too,
though this matters less in practice).
(Aside: I'm not sure I'd say that disabling a unit test counts as a "fix" ;)
I don't know if any of the above is relevant for your case. I've seen git-dpm
do weird things like take a single commit in the patches branch and turn it
into a quilt patch where the diff is present *twice*. I think this was for a
simple fix in pyparsing (trying to change distutils.setup() into
setuptools.setup() in the setup.py), and though I tried a ton of different
things, I was never able to get git-dpm to generate a correct quilt patch
file.
>At this point, I somehow merged pristine-tar into master :-(
You'll be way better off restarting from a fresh clone than trying to fix your
busted one. That way leads to madness. ;)
Cheers,
-Barry
pgptoBQfNWEsm.pgp
Description: OpenPGP digital signature
