Ben Hutchings writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On Thu, 2019-05-02 at 11:23 +0100, Ian Jackson wrote:
> > Sorry for shouting, but, really. It is kind of frustrating to have
> > designed and implemented and deployed a complex piece of software
> > which solves a lot of problems, and constantly hear people
> > - proposing solutions which do not address the primary difficulties
> > - merely lamenting that our current practices are so bad
> > - stating that the problems are intractable and cannot be solved
> > - saying that for this we need to agree a uniform git workflow
>
> We still need to resolve the issues with merging that I raised in
> October. (I say "we" because I realise you are likely to need me or
> someone else to spend time explaining and testing the specific
> scenarios that didn't work.)
That is to do with git-debrebase, not to do with dgit.
AIUI the current kernel team workflow has a bare-packaging git tree so
*if* you were to want to adopt dgit now you would want #903392 in
dgit, "want support for packaging-only maintainer views", implemented.
Packaging-only maintainer views are in a surprisingly large minority
but that minority largely consists of people who are using and keen on
quite old tools and workflows, and do not very much want to change.
>From the pov of a user/downstream who does `dgit clone': The benefit a
tarball import plus packaging git history (made by `dgit push' during
conversion from a packaging-only maintainer view), compared to a .dsc
import (tarball import, with patch queue converted to git branch, made
by `dgit clone' itself), is rather minor.
So that's why support packaging-only maintainer views is fairly low on
my todo list.
As for the linux kernel:
The proper git history is regarded by most people as the PFM. So you
would really want #903392 fixed in a way that let dgit reuse upstream
git tags (and dgit would have to check them against your orig
tarballs). This doesn't seem like something that many other people
would want but maybe it is ?
But all of this seems a lot of work to do for a quite suboptimal
answer when git-debrebase looks like it might be better, even though
there is still work to be done on git-debrebase. The work on
git-debrebase will have much wider applicability.
So yes, the Debian linux kernel team have a good reason for not using
dgit yet. Sorry if I gave a contrary impression. There will be some
other odd cases too no doubt, but what I said was true for most normal
packages maintained using tools like native git, gbp pq, git+quilt, or
git-dpm.
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.
