Re: [RFC] General Resolution to deploy tag2upload
Ian Jackson <ijackson@chiark.greenend.org.uk> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: