Simon McVittie writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Wed, 08 May 2019 at 12:18:41 +0100, Ian Jackson wrote:
> > Indeed, you yourself say you avoid gbp but for many packages, the
> > Vcs-Git header gives you a patches-unapplied format which requires[1]
> > gbp pq to switch to a patches-applied view before you build it.
>
> This step is not required: for 3.0 (quilt) packages, dpkg-source is happy
> with either patches-applied or patches-unapplied source directories,
> as long as you're at one extreme or the other
Yes. Perhaps indeed that's what the person I was responding to,
there, does.
However, this is actually quite dangerous. You definitely do not want
to rely on it. If dpkg-source's heuristic decides the patches have
already been applied, it will not apply them again.
The effect is that you might, for example, do this
1. debcheckout
2. dpkg-buildpackage -uc -b
3. examine result, looks good
4. git clean -xdff && git reset --hard # [1]
5. git cherry-pick 23891dcaf
6. dpkg-buildpackage -uc -b
7. dpkg -i
and if you are unlucky, the 2nd build in step 6 silently didn't apply
the patches, even though the 1st build in step 2 did. Whether you are
going to be unlucky is complicated.
[1] step 4 is needed because our build systems are often a mess.
There are other bizarre things about the state you get from
debcheckout with such a package. For example, `git grep'
can sometimes fail to find the thing you are looking for:
bubblewrap$ git --no-pager grep '^#!.*python3'
# .oO{ But my .deb says python3, wtf ? }
This is all very well if you are a seasoned Debian person and know
your way round the hall of mirrors. For someone with a passing
familiarity with git and no real Debian knowledge, it is a minefield.
To see what this looks like for a user, take a look at
https://manpages.debian.org/stretch-backports/dgit/dgit-user.7.en.html
and imagine what you would have to write in an equivalent manpage
based on debcheckout. debcheckout might give you an error message.
It might give you a CVS working tree!
Even if it succeeds and gives you git, it might give you a patches-
applied git-dpm or gdr branch. It might give you a patches-unapplied
gbp pq git branch. It might give you a multi-package packaging-only
monorepo. It might give you the top of a topgit pile. It might give
you a polyphonic multidimensional delta rhinoceros.
> Easier than the tool you have to use anyway (directly or indirectly)
> to build any package?
gbp pq import
- makes git grep work
- makes git log work
- makes git blame work
- leaves the tree clean
- means you can actually edit files and git-commit them!
I don't say it's perfect. Indeed I wrote a competing tool which has
an entirely different data model and different workflow, but that is
not really germane...
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.
