Hello, I started looking at implementing export-dsc this morning. My first thought was to have it work like the proposed changes to push-source in #886625 and #886966, so that push-source could call the export-dsc code.
This would mean that export-dsc would have the following behaviour:
- export the ref the user supplies on the command line
- if none, export git HEAD
- as a safety check in this second case only, refuse to proceed if
working tree is dirty and user has not passed --ignore-dirty
And push-source would behave like this:
- export the ref the user supplies on the command line, and push it
- refuse to do anything if working tree is dirty and user has not passed
--ignore-dirty
- if user supplies no ref, export git HEAD, and push it
- refuse to do anything if working tree is dirty and user has not passed
--ignore-dirty
But what happens when exporting a ref requires doing some quilt fixup
that requires making a commit, such as to update the contents of
debian/patches/? Where does that commit go?
We could discard the fixup commit after exporting the dsc. But this
option would be a bad idea when using `push-source` on an arbitrary ref,
as now dgit-repos is ahead of the maintainer's branches, which is always
confusing, and potentially very bad if using gdr.
We could advance the ref to include the fixup commit. So if I type
`dgit export-dsc foo-branch` then foo-branch might gain an extra commit.
But the ref supplied might be a remote-tracking branch or a tag, and we
can't advance those. So we would have to either
(a) append the commit when the ref the user supplied is a local
branch, but discard it when the ref the user supplies is anything
else, which would be confusingly inconsistent; or
(b) restrict export-dsc and push-source to accept local branches only.
I don't think (b) would be useful enough to justify the added code
complexity of support for arbitrary refs, because switching between
local branches in order to run export commands on different trees is
very easy for git users.
Another problem with advancing the ref in the case of export-dsc is that
it is quite unintuitive for an export command to make changes to the
thing that it is exporting. It's less bad when the thing that changes
is the branch you already have checked out.
My conclusion is that
- #886966 is wontfix
- #886625 can still be implemented, using playtrees
- #886969 should be the addition of an export-dsc cmd that takes no
arguments, and might commit to the currently checked out branch, plus
the deprecation of build-source (should export-dsc operate on git HEAD
like push-source after #886625, or the working tree?)
Can anyone see another way out?
--
Sean Whitton
signature.asc
Description: PGP signature
