Re: Preferred git branch structure when upstream moves from tarballs to git

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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 <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.