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 and dgit with maint-merge workflow produce). I don't > understand how gbp became so much more popular than git-dpm.
Some minor points and not an attempt for a complete answer: 0. Chances are you'll use gbp to build packages from git. So it is easier to know gpq pq if you are already familiar with gbp buildpackage. Anyone wants to either better integrate the two or re-implement dpm inside gbp? Have gbp (e.g.: dch) behave differently with either the option --git-dpm or with the presense of the file debian/.git-dpm? 1. It is more complex. I have a genuine fear of messing it up. Yes, this applies to git as well, but I long got over it. 2. The price of having patches represented but also representing their history is a complex history. More complex than it should be if you don't know how to edit it. Editing it is one point that I could not find in the man page (which is comprehensive, indeed). 3. No tab completion. Unlike gbp that completes commands well, though not always in a timely manner. Furthermore, I had to remember to run 'git-dpm --help', as 'git dpm --help' would give me a man page. Disclaimer: I have hardly used git-dpm in the recent year or so and switched mostly to gbp-pq. I like the idea, but the implementation was not comfortable enough for me to work with. And there were also some arguments of personal preference that don't apply in this discussion. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzaf...@cohens.org.il | | best tzaf...@debian.org | | friend
