Please review my merge request
Hola Team Members , Can someone review my Merge request and accept it if its okay . ( https://salsa.debian.org/python-team/modules/kivy/merge_requests/1) Thank you in Advance Manas Kashyap
Re: git-dpm -> gbp conversion (mass-change)
Thomas Goirand writes: > Let's say a patch has been applied upstream. In such case, I just do a > few "quilt push" to check, then I see one is already applied (by running > "patch --dry-run -P1 patch from the series file, and I'm done. In case of using git with the > rebase thing, then I get into useless trouble. This case is easy. When rebase comes up with a conflict, you can tell it to skip/drop that entire change. This tends to be my default choice when I don't understand why something conflicts during such a rebase. > Another case is if upstream moved sources from one directory to another. > In such case, I just edit the patch directly to fix the path. With a git > rebase, you'd probably have to rewrite all the patch by hand. Here > again, that's useless trouble. Yes, that case is harder to deal with. -- Brian May
Re: git-dpm -> gbp conversion (mass-change)
On Thu, 09 Aug 2018 at 10:16:31 +0200, Thomas Goirand wrote: > Now, if all goes well, and if the above cases are fixed, them I'm fine > using "gbp pq", but it's not any better than fixing by hand using quilt. One advantage of both quilt and gbp-pq over git-dpm (and probably git-debrebase) is that they interoperate: quilt and gbp-pq both work well in a "patches-unapplied" git repository. If one team member (for instance me) prefers to use gbp-pq, and another team member (for instance Thomas) prefers to use plain quilt, then we can share one git repository without significant problems: the worst that normally happens is a bit of unnecessary diffstat for the lines matching /^(git )?diff/, /^Index:/, etc. if one of us re-exports the whole patch series. I personally think gbp-pq is a better tool than quilt because it lets us use 'git rebase' on the patch series, but part of the point of choosing the gbp-pq-compatible repository layout is that it isn't either/or: we can use both. smcv
Re: git-dpm -> gbp conversion (mass-change)
Hi, čt 9. 8. 2018 v 10:16 odesílatel Thomas Goirand napsal: > Let's say a patch has been applied upstream. In such case, I just do a > few "quilt push" to check, then I see one is already applied (by running > "patch --dry-run -P1 patch from the series file, and I'm done. In case of using git with the > rebase thing, then I get into useless trouble. > if patch is already applied upstream, git-dpm/git autoremove that patch. What "trouble"? Another case is if upstream moved sources from one directory to another. > In such case, I just edit the patch directly to fix the path. With a git > rebase, you'd probably have to rewrite all the patch by hand. Here > again, that's useless trouble. > ugly (really). > Now, if all goes well, and if the above cases are fixed, them I'm fine > using "gbp pq", but it's not any better than fixing by hand using quilt. > it's much better :) -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: git-dpm -> gbp conversion (mass-change)
On 08/08/2018 09:19 PM, Nikolaus Rath wrote: > On Aug 08 2018, Thomas Goirand wrote: >> On 08/08/2018 01:38 PM, Nikolaus Rath wrote: >>> That doesn't make sense to me. git-dpm maintains (and rebases) Debian >>> patches separately, so upgrading to a new upgrade release can >>> principally not be any harder than with gbp. >> >> It is a nightmare when patches are conflicting. > > Could you give an example where this is handled differently by git-dpm > than by gbp? As I said, the problem is exactly the same. Here's a few cases where it gets nasty. Let's say a patch has been applied upstream. In such case, I just do a few "quilt push" to check, then I see one is already applied (by running "patch --dry-run -P1
