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"):
> > On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> > > Ansgar <ansgar@debian.org> writes:
> > > > Having to know about branches, merging, dealing with multiple remotes,
> > > > ... *is* an entry barrier compared to not having to know about it. Now
> > > > you have to teach people that before you even get to how to write a
> > > > build recipe.
> > >
> > > I'm confused. I'm a happy user of dgit and don't have to think about any
> > > of those things as part of using dgit. I choose to use branches, but I
> > > certainly wouldn't have to, and merging, multiple remotes, and so forth
> > > don't seem related to using dgit at all.
> >
> > 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.
Using dgit is a significantly higher entry barrier than not using it; I
wouldn't recommend using it for that reason.
> The "dgit" repository is also separate from the "real" repository;
> > if
> > you just use "dgit clone ${something}" you won't get the current
> > "master" branch (unless it happens to be identical to the last
> > release), or totally different if the maintainer doesn't use dgit.
> >
> > The history is also strange if you "dgit clone" a repository where
> > the
> > maintainer used dgit in the past, but no longer does. Now you have
> > a
> > commit tree with multiple roots which is also confusing for people.
> >
> > All of this is very uncommon outside the dgit world.
>
> 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.
(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.)
> (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?
Maybe dgit is useful for some people to maintain their packages in Git;
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).
Ansgar
Reply to: