>>>>> "Ian" == Ian Campbell <i...@debian.org> writes:
Ian> On Tue, 2019-05-07 at 11:01 -0400, Sam Hartman wrote: >> That said, I think Ansgar has some really valid points. I think >> that dgit (or git-dpm) are the hardest work flows to teach. Ian> I think perhaps you meant `git-debrebase` rather than `dgit` Ian> throughout the remainder of your mail, since comparing `dgit` Ian> and `git-dpm` is (AFAIUI) a type error of sorts since they are Ian> not serving the same purpose -- `dgit` replaces `dput` not your Ian> patch managment system so comparing it to `git-dpm`, a patch Ian> management system, is somewhat apples to oranges. I'm aware I'm making a typing error, and speaking in generalities. I agree that my statement is true for debrebase, but I meant the dgit ecosystem. git-dpm is harder than debrebase because it is less polished and involves more explicit branches in some ways. Dgit is harder overall even if you ignore debrebase because it has a lot of moving parts that in my experience sometimes fail and because dgit wants to get involved in your build process, wants to be aware of your patch management, etc. Dgit and debrebase are not really separate in terms of teaching. If you look at the documentation for debrebase, you'll find that there are a lot of cross references from debrebase docs to dgit. For example if you want to talk about handling new upstreams or orig tarballs with debrebase you need to talk about something else--either from the dgit ecosystem or the gbp ecosystem or something. Please understand I think dgit and debrebase are great technologies. I'm moving towards using them more and more, and when I'm acting as a downstream rather than a Debian developer, dgit clone is the best thing since sliced bread. Since I've mostly stopped eating bread perhaps I should come up with a new metaphor, but it's really neat regardless of what metaphor I use. Still, this stuff is hard.