Re: Preferred git branch structure when upstream moves from tarballs to git
On Fri, 2019-05-03 at 17:39 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream
> moves from tarballs to git"):
> > On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> > > Ansgar writes ("Re: Preferred git branch structure when upstream
> > > moves from tarballs to git"):
> > > > How do you update the package to a new upstream release?
> > >
> > > The same way you would with whatever tools you are currently
> > > using for
> > > that task. dgit is not a git delta management tool. For the
> > > maintainer, dgit replaces dput, not gbp pq or git-dpm or quilt.
> >
> > The question was to illustrate that dgit forces you to learn about
> > branches, merging, ... There is no workflow with dgit that doesn't
> > require this; when not using dgit, this isn't required.
>
> This is so wrong it is very perplexing to me.
Yet you confirm exactly what I am saying...
> This does not work right now with dgit because I have not taught dgit
> how to convert such a thing into a git tree that contains the actual
> source code.
I'm not talking about a hypothetical, different version of dgit which
might have a different set of features. Anything is possible for such
a hypothetical version.
> Using dgit is a significantly higher entry barrier than not using
> > it;
>
> Using dgit is a much lower entry barrier if you already know git, and
> don't know about Debian source packages. Like most people nowadays.
I know plenty of people who more or less only know git commit, push and
pull. Nothing more advanced.
> Using dgit is only a higher entry barrier if (i) you aren't
> comfortable with "intermediate" use of git (ii) you are already an
> expert on dpkg-source, quilt, etc.
Thank you for confirming that dgit raises entry barriers. I still
believe that is opposite of what distributions should do, see the
popularity of AUR or similar projects.
> Any maintainer who feels (as I often do) that the preferred form for
> modification of their package includes the full git history, should
> already be using dgit, since how else can they always discoverably
> publish the complete corresponding source ?
There is this fancy Vcs-Git field. Simple to discover.
Now, if dgit could just use that repository...
> [1] Possibly the user will get the maintainer's git history plus some
> autogenerated dgit conversion commits. For example, for a package
> whose maintainer uses gbp pq, the user gets a thing that has many
> similarities to the gbp pq patch queue branch. In particular, the
> patches are applied, each as a git commit in the user's history.
And then has to take care to not push those artificial commits
somewhere if that is not the preferred workflow... That seems rather
backwards to me.
Ansgar
Reply to: