Re: The Difference between debcheckout and dgit and what they try to accomplish
Sean Whitton writes ("Re: The Difference between debcheckout and dgit and what they try to accomplish"):
> It would seem, then, that what we want is merge requests against our
> interchange format: the source packages that actually get uploaded. Or,
> in other words, we want merge requests against the dgit view of
> packages. Presumably package maintainers to massage such a thing into a
> merge request against the maintainer view ... ?
For most[1] git workflows, every MR to the dgit view could be
automatically converted to a MR against the maintainer view. The
conversion is generally quite simple - indeed, it is usually simply a
particular arrangement of existing maintainer workflow tooling.
The exception would be new-upstream-version. It is *possible* to use
dgit and git-debrebase together to do a new-upstream-version of *any*
package but the resulting git history is not very sane, and I think
not really suitable for such an automatic conversion. I think in
practice, at least unless we want to do a lot of extra work,
new-upstream-version must be done with the maintainer view.
The resulting maintainer-MR would not be FF from the submitter-MR, but
it is not uncommon with "MR" approaches outside-Debian, for the
maintainer to rebase or squash or otherwise mangle the submitted MR
branch, so that the master does not become FF from the submitted MR.
So I don't think this is a significant problem.
Ian.
[1] Some workflows have automatically generated files - eg d/control -
in the dgit/.dsc view. Edits to the dgit view which change
automatically generated files are not automatically back-convertable.
Indeed some such changes may not be representable at all in the
maintainer view...
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: