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 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.
Or do you mean, when doing an NMU campaign ? I wasn't aware that
Debian encouraged NMU campaigns involving new upstream versions.
If you want to do an NMU involving a new upstream version then
*somehow* you are going to have to do some patch rebasing. There are
broadly speaking three options
- Figure out what workflow the maintainer is using, and follow it
(learning their tooling and their workflow if necessary). This is
a pain. It's especially a pain if you're less of a Debian expert.
Debian experts already know N different git packaging workflows.
- Mess about with tarballs and patches. Yuk.
- Choose your faviour a git packaging rebase tool and convert
whatever the maintainer published into the format needed by your
tool. IME this works OK and generally produces a `3.0 (quilt)'
.dsc that no-one will object to.
- Use git merge and convert to 1.0 or single-debian-patch.
(No-one will thank you for this!)
Because NMUing new upstream versions is rather a minority sport, I
haven't prioritised documentation or tooling for this. But when
necessary, I would do it with git-debrebase convert-from-dgit-view
followed by git-debrebase new-upstream. This is IME very effective
but it's my tool and I would say that.
> 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)
(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)
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: