Re: Preferred git branch structure when upstream moves from tarballs to git
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.
Maybe Russ has it, when he says:
Are you using a separate repository for only the debian directory and
merging that with an unpacked upstream tarball without using a version
control system to do so? I don't know how that works with dgit if
that's the case.
?
In answer to Russ's implied question.
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. That feature would be the wishlist bug
#903392 "want support for packaging-only maintainer views"
which I've already mentioned once in this thread, where I explained
why implementing it is a low priority.
If Russ has described guessed right then even so it is *not* true that
"dgit forces you to learn about branches, merging,...".
It's just that dgit does not yet know how to convert your git branch
into the kind of git branch that other people want. If it did (that
would be me implementing #903392) then you would still not need to
learn anything you do not already know. You would just say `dgit
push', from your existing working tree, and dgit would do its thing
automatically.
Maybe you are interpreting "please use dgit" to include "please switch
to a git tree containing the upstream source code". That is not
correct.
It is true that switching to a git tree containing the upstream source
code (and the upstream git history) does involve multiple branches.
While obviously Russ and I think git trees should containin the
upstream source code, no-one is asking you to do that "because dgit".
> 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.
Indeed dgit's key benefit is that it helps you avoid having to learn
about Debian source packages. This is useful because Debian source
packages are, by modern standards, crazy, and seriously defective.
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.
> > If you are trying to get the source code, there is a choice to be
> > made.
> >
> > You can choose to
> >
> > (1) Get a predictable standardised tree format, which can directly be
> > built, cherry-picked, etc.,
> >
> > And, always have what is actually in the archive.
> >
> > But maybe an unhelpful history. Especially, if the maintainer
> > does not use dgit push.
> >
> > (dgit clone)
>
> This doesn't give you the real source according to people who state
> that "source code" nowadays means the Git repository used by the
> maintainer. dgit doesn't differ from apt-get source & gbp import-dsc
> there, at least I don't see one.
Yes, people who state that the source code nowadays usually means the
git repository consider that a Debian source package is not the proper
source code either. The Debian "source" archive is not really a
source archive.
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 ?
> (This might be different for packages where the maintainer is using
> dgit, didn't forget to push and didn't make any changes since the last
> upload, i.e. when debcheckout would give the same result.)
If the maintainer uses `dgit push' then the user who uses `dgit clone'
gets the maintainers' git history. [1] That's the whole point.
Whether they `forgot to push' (to salsa I guess) is not very relevant.
The source code that ought to be published along with the .debs is not
some random other more recent version. It is the source code that
produced the .debs that the user is running. dgit gives the user
exactly that.
[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.
> > (2) Have an unpredictable (and usually not even specified) tree
> > format, which may (and usually will) require use of
> > git-workflow-specific tools to even build it.
> >
> > Have to understand the maintainer's branch structure to try to
> > figure out which version corresponds to what is in the archive.
> >
> > Have the maintainer's history. This is usually in a format
> > useful to the maintainer, but it is not standardised. It may be
> > the packaging history for a whole packaging ecosystem. It may be
> > a linear history of a gbp pq branch. It may be a git-dpm history
> > containing multiple rebases of the same patch series.
> >
> > (debcheckout)
>
> It has the advantage of having the history if one cares about it. Why
> would one not prefer that over the result of importing the .dsc
> somewhere?
Because you can build it ? And because you can git-cherry-pick,
and git-grep and git-commit and git-clean and git-reset and ...
(all without knowing what tribe the maintainer belongs to.)
> Maybe dgit is useful for some people to maintain their packages in Git;
dgit is not a tool for maintaining packages in git.
That is what git-dpm and git-debrebase and gbp pq are for.
> but it's not helpful for packages where the maintainer is using it and
> some complications are just not a good idea IMHO (like using a separate
> Git repository with potentially different contents and not warning
> users when fabricating history different from the real VCS history).
dgit prints ample messages when it has to perform a dsc import.
And the result is hardly unobvious in git log or gitk or whatever.
That when the maintainer uses dgit push, tree contents from dgit clone
may differ, is inevitable from the facts that:
1. Debian maintainers prefer to use a variety of different
mutually incompatible git tree formats the most common
of which cannot even be directly built (!)
2. We should provide software to users in a standardised form, and
indeed a form that can be built. (This is controversial!!)
The result is that the tree must be converted. As a maintainer who
does `dgit push' you do not need to worry about this because dgit will
do it all automatically and you never need to see dgit's converted
view of your package.
And the maintainer's history is an ancestor of the dgit view history,
so everything is visible to the `dgit clone' user (and git blame and
so on all work correctly).
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.
Reply to: