Hello, On Mon 13 May 2019 at 11:49AM +01, Ian Jackson wrote:
> Sean Whitton writes ("Bug#928503: Want "dgit reportbug" to submit a patch, or
> something"):
>
>> I think that in the vast majority of cases this tool would produce the
>> needed output even if your git tree was not obtained with dgit clone, so
>> I would hope that it could be completely decoupled from dgit.
>
> Maybe. The question isn't really whether the git tree was made by
> dgit clone, but:
> * what format the NMUer's tree is in
> * where we obtain the prior-to-NMU git view
>
> If we assume that the NMUer's git branch is as if from dgit
> clone/fetch branch, and that the NMUer has worked in a way that would
> be appropriate for dgit quilt-fixup, then we can obtain the
> prior-to-NMU git view from `dgit fetch', and everything is a SMOP.
>
> I think the result would need dgit only for dgit fetch. But I don't
> see what dgit fetch could be replaced with. And the NMUer's workflow
> must be dgit-NMU-ish (make commits to actual files; ignore
> debian/patches; no merging).
>
> If we can't make these assumptions then: what if the NMUer used
> vcs-git and some salsa branch ? What if the NMUer uses some gbp pq
> NMU workflow (I have no idea if such a thing is even possible, but I
> bet there are people who do something like this) ? What if the NMUer
> manually created a file in debian/patches ? etc.
Hmm, I think I was implicitly assuming that the user would supply a
revision range, rather than the tool trying to guess that range.
I'm undecided how important it to automatically determine the revision
range.
--
Sean Whitton
signature.asc
Description: PGP signature
