Control: retitle -1 dgit: build-source and push-source disregard -wc On Wed, Oct 10, 2018 at 01:51:44AM +0100, Ian Jackson wrote: > Control: clone -1 -2
[ replying to the clone here! ]
> FYI, I discovered some other weirdness with what you were trying to
> do.
>
> Firstly, from your transcript, you didn't commit debian/source/format.
> It's an un-ignored un-tracked file. dgit nowadays always builds
> source packages in a private area and bases them on your git tree.
> The result is that if you do what you did it will (i) notice the
> debian/source/format in the working tree and decide to do quilt
> linearisation (ii) call dpkg-source --commit in the private area in a
> clean tree with no debian/source/format. The result is a 1.0 package.
> This is arguably a bug. But the only thing dgit could sensibly do
> would be to spot that yuu did this and stop with a complaint.
Right. I also thought about it later, and decided to try with
--include-dirty.
What I had expected, especially using -wc, was to give up istantly with
a "your working tree is dirty" message, and to go on including my
uncomitted changes with --include-dirty.
But from what you say it is going to do neither.
> I experimented with committing debian/source/options. If I do that
> dgit makes a hamfisted attempt at quilt linearisation: again, it
> attempts to call dpkg-source --commit starting at a commit which does
> not have debian/source/format. I will fix dgit to stop quilt
> linearisation when it encounters a change to debian/source/format, and
> you would then get this error message:
> dgit: error: quilt fixup cannot be linear. Stopped at:
> dgit: 45a228db..d5c44c79: changed debian/source/format
> along with some essentially useless suggestions.
>
> What you are asking dgit to do is rather outside of its scope. The
> quilt linearisation feature is intended to support an NMUer or user
> adding a few commits on top. It is not intended as a general puprose
> git workflow and delta queue management tool. It certainly isn't
> intended for converting from 1.0-with-diff to `3.0 (quilt)'.
Consider that I didn't know that there were actually changes to the
upstream code back then. After I filed the bug I manually ran
`dpkg-source -b .` and *here* I discovered that there were changes, at
which point I ran `dpkg-source --commit` to get them in patch format.
> I infer that you want to do `3.0 (quilt)' with this package, and
> you're using git, so you will need a git workflow tool. Which one are
> you intending to use ? Perhaps the real problem is that you intend to
> use git-debrebase but forgot to convert the branch (with git-debrebase
> convert-from-dgit-view) ? Or that you intend to use gbp pq but didn't
> make a pq branch and export it ?
I only wanted to move to 3.0 out of dislike for 1.0. I don't really
care about any patch regime here (after all, it's a one-time QA upload
I'm doing). So, the single patch provided to me by dpkg-source --commit
is more than great.
I think that for that, the usual quilt linearisation that I saw dgit
doing in the past is cool enough.
> But having done that IDK how you would rebase onto a new upstream
> version. You'll definitely need a workflow tool for that (or I guess
> you could do it by hand with raw git runes if you had iron
> concentration and an iron constitution).
Once the patch is committed in quilt, I'd expect to use any random tool
for rebasing the patches? I mean, the issue you are referring to here
sounds very orthogonal from the title of this bug report.
> Also, arguably something should have stopped you proceeding with an
> untracked unignored files (perhaps, especially as you specified -wc).
> But the clean mode is basically ignored with build-source (and
> push-source) since the tree does not need to be cleaned. But spotting
> uncommitted files is important. I'm not sure exactly what to do about
> this but I have cloned this bug to track this issue. It seems odd to
> say that --clean=check ought to make build-source and push-source
> check for loose files, even though they usually don't actually clean
> the tree at all. Perhaps there should be a separate check which
> doesn't depend on the clean mode ?
Again, for clearity, I'd expect:
* -wc to always stop *any* command from running if the working tree is
not fully committed
* --include-dirty to do some magic to include the untracked files in
whatever dgit is going to do
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
