Hi Julien. i see your points. let me try to clarify things a bit. sorry if i am annoying the other receipients.
On Sun, Aug 10, 2014 at 10:53:10PM +0200, Julien Puydt wrote: > (1) the manpage says git-dpm uses a "patched" branch, and I don't see it in > "git branch -a" the patched branch is accessible with 'git-dpm checkout-patched'. pushing it to the public repo is unnecessary/redundant (and harmful, as someone might expect it to retain history). once the package is ready, you may use "git-dpm tag" to add a shiny immutable tag to it. > (2) git-buildpackage is happy with the current packaging because it doesn't seem to care about how patches are organized. > (3) pristine-tar has no problem checking out upstream tarballs dito. > (4) we're discussing for a single patch which is going away in the next > version it's about whether the patch has been committed to the packaging branch or to an upstream+patched branch. maybe you know how to rebase a missorted patch to a new upstream version. i don't. git-dpm doesn't know, and presumably git-buildpackage is not meant to do such things. (yes, there is gbp-pq, and i admit that i do not understand how it is supposed to work. my guess is, it cannot rebase in this situation either). the patch in question appears to be a cherry-pick from future upstream, so it has been a git commit from the beginning. git will know how to rebase it back to upstream. > (5) I can't help but notice that git-dpm complains about two files > containing non-debian change... and one of them is fmpz/test/t-invmod.c > which is pristine upstream! fmpz/test/t-invmod.c has been edited in 90b70c2cce, a commit to the master (packaging) branch. this is the whole trouble. > I really have the impression that only git-dpm is unhappy with my package, > and that the only reason why it's complaining is that I don't use it. It > would be nice to use it, but (4) says it might be quite overkill, and (5) > says git-dpm is going to make it hard, since it won't even recognize > pristine upstream for what it is. you do not have to use git-dpm to not commit upstream changes to the debian branch. i don't see how the total number of patches changes this or how git-dpm is making it any harder. > So, what should I do? 1 revert the commit in question 2 commit the change on top of the upstream branch 3 merge the patched upstream branch into master 4 update debian/patches it doesn't matter much if you use git-dpm or not. doing things manually is just a bit more involved. for example 2 find the current patched branch... (here: just take upstream and forget about that one patch) 3 what was the right strategy option again? -srecursive -Xtheirs. maybe 4 git show will show your commit, but will the format be ok? don't forget to update series. independendly, you may want to plough debian/.git-dpm. expect some questions from a clueless about how to do stuff without git-dpm... cheers, hth felix -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
