Re: git-dpm -> gbp conversion (mass-change)
Ruben Undheim writes: > There is no nightmare unless there are patch conflicts. The one case where you could have a "nightmare" is: 1. Maintainer A updates package to latest upstream version. 2. Maintainer A uploads packages to Debian, and it is accepted. 3. Maintainer A forgets to push changes to git. Or doesn't push all branches/tags as required. 4. Maintainer B finds package, and updates to latest upstream version (which could be later then what maintainer A saw). 5. Maintainer B pushes changes to git. 6. Somebody complains that fixes that where included in the first version have now gone missing. 7. Maintainer A pushes his changes, find they are rejected, and wrongly does a "push -f", loosing the changes from maintainer B. OR 7. Maintainer A realizes what has happened, has two sets of patches against two different upstream versions, and somehow needs to reconcile them. etc, etc. However, I don't know of any workflow that would make the issues here any easier. Moral of the story, always make sure you pull changes (from all branches) before starting to work, just to make sure nobody else has made changes. Plus always make sure you push changes (all required branches, e.g. "git push origin : --tags") after you finish work. Easy to forget however. -- Brian May
Re: git-dpm -> gbp conversion (mass-change)
Nikolaus Rath writes: > The problems with git-dpm are the implementation and lack of > maintenance, not the way the Debian changes are managed. git-dpm requires that you always use its tools. If another maintainer got confused and used another toolset to upgrade the upstream version, things could get messy. I did see it happen from time to time that the previous maintainer would leave the repository in a weird state that could only be fixed (unfortunately) with a git rebase. -- Brian May
Re: git-dpm -> gbp conversion (mass-change)
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. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: git-dpm -> gbp conversion (mass-change)
On 08/08/2018 03:55 PM, Ruben Undheim wrote: > Hi, > >> The problem with git-debrebase will be the same as with git-dpm. As soon >> as you try to upgrade / merge a new upstream release, you dive into a >> rebase/conflict nightmare. > > So in other words, you prefer to solve the same conflicts manually with > quilt/quilt refresh Yes. Whenever a patch cannot be applied, generally, applying it manually to do the rebase is much easier than with just git. ie: just use patch, then manage whatever's left in the .rej files, then dpkg-source --commit the result. In my experience, it is much easier to see what's going on rather than solving a merge conflict with git. > There is no nightmare unless there are patch conflicts. Of course. But it is these cases which we care about here. > All the tools will > in that case give you a nightmare in one way or the other. It is just that > some > of them attempt to handle it a bit more elegantly than the others. I don't think we care if it is elegant. We care efficiency, manageability, and above all: to always understand what's going on. > For people familar with git (and rebase) - the nightmare should not be bad > at all with git-debrebase. I have experienced all sorts of weird situation where it was really hard to figure out what was coming from before the rebase, and after it, just by reading the source code. It's often a lot easier to just read the patch, and try to manually modify the code to do what the patch suggests ... or not! That's the important bit. Be able to see what's going on and take a wise decision. Cheers, Thomas Goirand (zigo)
Re: git-dpm -> gbp conversion (mass-change)
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. > The problems with git-dpm are the implementation and lack of > maintenance, not the way the Debian changes are managed. I don't agree. Thomas
Re: git-dpm -> gbp conversion (mass-change) [phase 1 DONE]
Hi, pá 3. 8. 2018 v 5:06 odesílatel Ondrej Novy napsal: > 1. convert git-dpm -> gbp > this is done. -- 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)
Hi, > The problem with git-debrebase will be the same as with git-dpm. As soon > as you try to upgrade / merge a new upstream release, you dive into a > rebase/conflict nightmare. So in other words, you prefer to solve the same conflicts manually with quilt/quilt refresh or get similar but worse (I think) rebase conflicts with "gbp pq rebase"? There is no nightmare unless there are patch conflicts. All the tools will in that case give you a nightmare in one way or the other. It is just that some of them attempt to handle it a bit more elegantly than the others. For people familar with git (and rebase) - the nightmare should not be bad at all with git-debrebase. (personally I solve conflicts with quilt -f /quilt refresh when using gbp).. Cheers, Ruben
Re: git-dpm -> gbp conversion (mass-change)
On Aug 08 2018, Thomas Goirand wrote: > On 08/04/2018 09:05 AM, Ruben Undheim wrote: >> Hi, >> 2/ Ondrej Novy will do a mass-change from git-dpm to gbp on team packages. Related to this, Piotr will review and amend the team policy if necessary, as well as work on the pipeline to make sure the policy gets published from salsa. >> >> Good initiative! The last upload of git-dpm was in 2014. >> >> But have anyone here tried the new tool git-debrebase (by Ian)? Should it be >> evaluated before doing a mass change for Python packages? It integrates even >> better with dgit (of course..) > > The problem with git-debrebase will be the same as with git-dpm. As soon > as you try to upgrade / merge a new upstream release, you dive into a > rebase/conflict nightmare. 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. The problems with git-dpm are the implementation and lack of maintenance, not the way the Debian changes are managed. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: git-dpm -> gbp conversion (mass-change)
On 08/04/2018 09:05 AM, Ruben Undheim wrote: > Hi, > >>> 2/ Ondrej Novy will do a mass-change from git-dpm to gbp on team packages. >>> Related to this, Piotr will review and amend the team policy if necessary, >>> as >>> well as work on the pipeline to make sure the policy gets published from >>> salsa. > > Good initiative! The last upload of git-dpm was in 2014. > > But have anyone here tried the new tool git-debrebase (by Ian)? Should it be > evaluated before doing a mass change for Python packages? It integrates even > better with dgit (of course..) The problem with git-debrebase will be the same as with git-dpm. As soon as you try to upgrade / merge a new upstream release, you dive into a rebase/conflict nightmare. Cheers, Thomas Goirand (zigo)
