Ian Jackson <[email protected]> writes: > Russ Allbery writes ("Re: [RFC] General Resolution to deploy tag2upload"):
>> So yes, you're right, the git-debrebase example is not nearly as >> interesting as I had thought because the tooling works differently than >> I had realized. > As ever, it's all more complicated than you thought (and than you now > think). I'm going to give just a few examples of the frantic paddling > that dgit is doing underneath the waterline. This is therefore an > *extremely* long message. This is fantastic, Ian. Thank you so much for writing all of this up. Entirely apart from the current debate, I learned a ton about Debian source packaging and workflows from this. > However, you can also run `dgit push-source --split-view=always`. This > is an alternative workflow. In that case, the synthetic git commits > which introduce d/patches don't end up in your own maintainer git > branch. (I'm not sure Russ knows this feature exists.) This mode is > nicer because you don't get diff noise about changes to the completely > autogenerated contents of d/patches. Specifically, without the split > view, each upload introduces a bunch of patches onto the maintainer > branch, which the next run of git-debrebase after the upload immediately > deletes. Aha, this is the workflow that I mistakenly thought I was using because I had never checked. Thank you! Keeping the generated debian/patches/* files off of my development branch is exactly what I want, so I suspect this is the workflow that I want to be using and I should switch to it. I had always wondered what "split view" meant but had never taken the time to read the documentation properly and understand it. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
