Re: Converting to dgit

On Thu, 2017-01-12 at 21:46 +0100, Raphael Hertzog wrote: > Hi, > > On Fri, 06 Jan 2017, Ghislain Vaillant wrote: > > > I don't use it often enough to remember all the details either. I don't > > > recall the last time I had to do more than copy/paste a command from the > > > man > > > page

Re: Converting to dgit

Hi, On Fri, 06 Jan 2017, Ghislain Vaillant wrote: > > I don't use it often enough to remember all the details either. I don't > > recall the last time I had to do more than copy/paste a command from the > > man > > page (OK, git-dpm tag I can remember). > > Besides, git-dpm usually tells you

Re: Converting to dgit

Sean Whitton writes ("Re: Converting to dgit"): > It's not so much the number of commands, but the distraction: thinking > about a patch queue while in the middle of thinking about actual bugs. > Personally, I find that mentally significant. People who are used to trying t

Re: Converting to dgit

Hello Nikolaus, On Sat, Jan 07, 2017 at 01:08:02PM -0800, Nikolaus Rath wrote: > Aeh, what? > > If you make changes to debian/, you need only 'git commit'. > > If you change something in the upstream source (aka, add a new patch), > the "dance" is: > > $ gbp pq import > $ # make changes > $

Re: Converting to dgit

On Jan 06 2017, Sean Whitton wrote: > Hello Nikolaus, > > On Thu, Jan 05, 2017 at 03:59:40PM -0800, Nikolaus Rath wrote: >> On Jan 05 2017, Sean Whitton wrote: >> > On Thu, Jan 05, 2017 at 12:39:25PM -0800, Nikolaus Rath wrote: >> >> But, as

Re: Converting to dgit

Hello Nikolaus, On Thu, Jan 05, 2017 at 03:59:40PM -0800, Nikolaus Rath wrote: > On Jan 05 2017, Sean Whitton wrote: > > On Thu, Jan 05, 2017 at 12:39:25PM -0800, Nikolaus Rath wrote: > >> But, as far as I can tell, doing this work up-front is much easier: > > > > Yes,

Re: Converting to dgit

On Fri, 2017-01-06 at 00:41 -0500, Scott Kitterman wrote: > On Friday, January 06, 2017 12:29:54 AM IOhannes m zmölnig wrote: > > On 01/04/2017 05:42 AM, Colin Watson wrote: > > > git-dpm does too, and I agree it's nice. > > > > here's an opposite data point: > > > > being forced to use git-dpm

Re: Converting to dgit

On Friday, January 06, 2017 12:29:54 AM IOhannes m zmölnig wrote: > On 01/04/2017 05:42 AM, Colin Watson wrote: > > git-dpm does too, and I agree it's nice. > > here's an opposite data point: > > being forced to use git-dpm by the python-modules-team policy - i > haven't had a single joyful

Re: Converting to dgit

On 01/04/2017 05:42 AM, Colin Watson wrote: > git-dpm does too, and I agree it's nice. here's an opposite data point: being forced to use git-dpm by the python-modules-team policy - i haven't had a single joyful experience with git-dpm. so far, every import of a new upstream release turned into

Re: Converting to dgit

On Jan 05 2017, Sean Whitton wrote: > On Thu, Jan 05, 2017 at 12:39:25PM -0800, Nikolaus Rath wrote: >> But, as far as I can tell, doing this work up-front is much easier: > > Yes, but you have to do it every single time you make changes that you > want to be able to

Re: Converting to dgit

On Thu, Jan 05, 2017 at 12:39:25PM -0800, Nikolaus Rath wrote: > But, as far as I can tell, doing this work up-front is much easier: Yes, but you have to do it every single time you make changes that you want to be able to push (i.e. more than once per upload). For a lot of packages I maintain,

Re: Converting to dgit

On Jan 05 2017, Sean Whitton wrote: > Dear Nikolaus, > > On Wed, Jan 04, 2017 at 09:44:14AM -0800, Nikolaus Rath wrote: >> No, that's a misunderstanding. >> >> "The information I need" is the Debian-specific modifications to the >> current upstream source, separated

Re: Converting to dgit

Dear Nikolaus, On Wed, Jan 04, 2017 at 09:44:14AM -0800, Nikolaus Rath wrote: > No, that's a misunderstanding. > > "The information I need" is the Debian-specific modifications to the > current upstream source, separated into logically independent patches. > > Having separate patches in

Re: Converting to dgit

Simon McVittie writes: > I think the bottom line here is that what you are doing *is* rebasing: > you are treating the new upstream (or new security-patched downstream) > as the new baseline for your local work, discarding any of your changes > that are no longer necessary, and

Re: Converting to dgit

On Jan 04 2017, Sean Whitton wrote: >> > I also read Russ's e-mail, but I'm not yet convinced that powerful tools >> > like `git diff` and `git log` won't be able to give you the information >> > you need pretty quickly. >> >> Can you give an example? Eg if I have to

Re: Converting to dgit

On Tue, 03 Jan 2017 at 22:17:33 -0800, Russ Allbery wrote: > Usually what I have to do (and I think this is a pretty common use case > for anyone who customizes Debian packages) is that I need to start from a > package from unstable (or at least newer than stable, or oldstable, or > ancient

Re: Converting to dgit

Nikolaus Rath writes ("Re: Converting to dgit"): > I still haven't really made up my mind if I want to use git-maint-merge > or git-dpm. Russ recently raised a valid point with the Debian > modifications over-time becoming all tangled up and impossible to > separate. I

Re: Converting to dgit

Hello, On Tue, Jan 03, 2017 at 04:33:39PM -0800, Russ Allbery wrote: > Curating a patch series is only 5% slower than commiting directly to the > Git repository to me. I just have to remember to gbp pq import before > making new changes, gbp pq export when I'm done, and once in a great while > I

Re: Converting to dgit

On Tue, Jan 03, 2017 at 07:01:22PM -0800, Nikolaus Rath wrote: > When talking about percentages, I think it's worth keeping in mind the > 1000% longer that it takes to comprehend a diff of two patches-unapplied > trees (as gbp produces them) over a diff of two patches-applied trees > (as git-dpm

Re: Converting to dgit

Nikolaus Rath writes: > On Jan 03 2017, Russ Allbery wrote: >> Speaking as a Debian user who frequently has to apply local patches or >> produce local versions of Debian packages for my job (usually weird >> backports or bizarre local requirements), I cannot

Re: Converting to dgit

On January 4, 2017 12:33:43 AM EST, Nikolaus Rath wrote: >On Jan 03 2017, Russ Allbery wrote: >> Nikolaus Rath writes: >> >>> The thing that's delivered to users in 99% of the cases is the >binary >>> package. In the (comparatively) rare

Re: Converting to dgit

On Jan 03 2017, Russ Allbery wrote: > Nikolaus Rath writes: > >> The thing that's delivered to users in 99% of the cases is the binary >> package. In the (comparatively) rare cases where the user is retrieving >> the source, I am not convinced that most of

Re: Converting to dgit

On Wed, 2017-01-04 at 14:47 +1000, Russell Stuart wrote: > The central issue here appears to be that none of the proposed ways > of using git within Debian help with that task. On Wed, 2017-01-04 at 04:42 +, Colin Watson wrote: > > git-dpm does too, and I agree it's nice. > > It produces a

Re: Converting to dgit

On Tue, Jan 03, 2017 at 07:36:46PM -0800, Russ Allbery wrote: > That said, gbp pq does something else I really like, namely it exports in > the source package all of the metadata that anyone else would need to pick > up the package without needing a copy of my Git repository (except for >

Re: Converting to dgit

Nikolaus Rath writes: > The thing that's delivered to users in 99% of the cases is the binary > package. In the (comparatively) rare cases where the user is retrieving > the source, I am not convinced that most of these users truly prefer a > Debian-specific source package

Re: Converting to dgit

Nikolaus Rath writes: > When talking about percentages, I think it's worth keeping in mind the > 1000% longer that it takes to comprehend a diff of two patches-unapplied > trees (as gbp produces them) over a diff of two patches-applied trees > (as git-dpm and dgit with

Re: Converting to dgit

On Jan 04 2017, Scott Kitterman wrote: >>Curating a patch series is only 5% slower than commiting directly to >>the Git repository to me. I just have to remember to gbp pq import >>before making new changes, gbp pq export when I'm done, and once in a >>great while I have to

Re: Converting to dgit

On Jan 03 2017, Russ Allbery wrote: > Sean Whitton writes: >> On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote: > >>> I still haven't really made up my mind if I want to use git-maint-merge >>> or git-dpm. Russ recently raised a valid point

Re: Converting to dgit

On Jan 03 2017, Sean Whitton wrote: > On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote: >> I still haven't really made up my mind if I want to use git-maint-merge >> or git-dpm. Russ recently raised a valid point with the Debian >> modifications over-time

Re: Converting to dgit

On Tue, Jan 03, 2017 at 04:33:39PM -0800, Russ Allbery wrote: > I'm unconvinced that any of that work would really be avoided via other > mechanisms. The most time-consuming part is rebasing and squashing > related changes together into one coherent diff, but that's going to be > just as hard

Re: Converting to dgit

On January 3, 2017 7:33:39 PM EST, Russ Allbery wrote: >Sean Whitton writes: >> On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote: > >>> I still haven't really made up my mind if I want to use >git-maint-merge >>> or git-dpm. Russ recently

Re: Converting to dgit

Sean Whitton writes: > On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote: >> I still haven't really made up my mind if I want to use git-maint-merge >> or git-dpm. Russ recently raised a valid point with the Debian >> modifications over-time becoming all

Re: Converting to dgit

Hello Nikolaus, On Tue, Jan 03, 2017 at 10:29:49AM -0800, Nikolaus Rath wrote: > On Jan 03 2017, Sean Whitton wrote: > > You mentioned previously that you're trying to use the > > dgit-maint-merge(7) workflow. In that case, why do you want git-dpm? > > I don't. I was

Re: Converting to dgit

On Jan 03 2017, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > Sean Whitton writes ("Re: Converting to dgit (was: How to get history into > dgit)"): >> On Mon, Jan 02, 2017 at 07:22:54PM -0800, Nikolaus Rath wrote: >> > I'll have to bring this up

Re: Converting to dgit

On Jan 03 2017, Sean Whitton wrote: > Hello Nikolaus, > > On Mon, Jan 02, 2017 at 07:22:54PM -0800, Nikolaus Rath wrote: >> I'll have to bring this up one more time. I just read >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794244, and that >> sounds (in "USING

Re: Converting to dgit (was: How to get history into dgit)

Sean Whitton writes ("Re: Converting to dgit (was: How to get history into dgit)"): > On Mon, Jan 02, 2017 at 07:22:54PM -0800, Nikolaus Rath wrote: > > I'll have to bring this up one more time. I just read > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79

Re: Converting to dgit (was: How to get history into dgit)

Hello Nikolaus, On Mon, Jan 02, 2017 at 07:22:54PM -0800, Nikolaus Rath wrote: > I'll have to bring this up one more time. I just read > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794244, and that > sounds (in "USING GIT-DPM WITH DGIT FOR THE FIRST TIME") as if I should > also stitch the

Converting to dgit (was: How to get history into dgit)

On Dec 11 2016, Nikolaus Rath wrote: >>> I would like to start using dgit for one of my packages, using the >>> dgit-maint-merge workflow. >>> If I understood correctly, following the dgit-maint-merge(7) >>> instructions for the initial setup will give me a repository with only