Mattia Rizzolo writes ("Re: Bug#910687: dgit: build-source and push-source
disregard -wc"):
> 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.
Mmm, that seems like reasonable expectations - at least the first
half. I didn't try with --include-dirty. You were intending to push,
right ? You can't push with --includ-dirty.
> But from what you say it is going to do neither.
I think with --include-dirty it might do what you expected. With that
option it builds the source package from your own working tree.
> > 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.
IMO 1.0 with diff has some compelling advantages over 3.0
single-debian-patch. One of them is that there is none of this
committing patches nonsense.
> I think that for that, the usual quilt linearisation that I saw dgit
> doing in the past is cool enough.
dgit's quilt linearisation requires that your tree is a linear (or at
least linearisable) sequence of commits on top of { the original
upstream source + your debian/ directory + whatever patches are in
d/patches already applied }.
You never made a commit like that. The dgit import isn't because it
doesn't have debian/patches because it was an import of a
1.0-with-diff package.
Or to put it another way, dgit quilt fixup transforms a branch which
is a patches-applied git tree plus some additional commits into a new
patches-applied git tree whose operative files are the same. But you
had no patches-applied git tree to start with.
> > 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.
Yes, it is orthogonal. I'm trying to find out what you were trying to
do and why and maybe give helpful advice (via docs or direct to
you...)
You say `use any random tool for rebasing the patches' but what tool
would that be ? I don't think gbp pq can operate on a patches-applied
tree, can it ?
> Again, for clearity, I'd expect:
> * -wc to always stop *any* command from running if the working tree is
> not fully committed
I think in fact that this needs to be more general. For example, with
--clean=dpkg-source: if dpkg-source leaves untracked files, this
should be detected. I think this check should happen any time dgit
builds a source package.
> * --include-dirty to do some magic to include the untracked files in
> whatever dgit is going to do
I think that should already work.
Anyway, thanks for exploring all this with me.
Regards,
Ian.
--
Ian Jackson <ijack...@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.
