Re: Preferred git branch structure when upstream moves from tarballs to git
Ben Finney writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > [...] I have not taught dgit how to convert [separate Debian
> > packaging-only repository and upstream source repository] into a git
> > tree that contains the [combined] source code.
>
> One interpretation of `convert [separate repositories] into [one Git
> tree]' is that it's a flag-day, point of no return conversion that
> precludes the separate-Debian-packaging-repository workflow from that
> point forward. If so, that wouldn't be enough to convince me to use
> DGit, because I consider the separate-Debian-packaging-repository
> workflow superior for many cases.
Sorry that I have apparently been unclear.
That's not how dgit copes with "special" maintainer git practices.
Rather, the maintainer's thing (whatever that is) is converted anew
*at each upload* (ie at each dgit push). The converted version is
published to dgit users (using an appropriate history structure[1].
The maintainer does not see the output of the conversion, unless they
go looking for it.[2] These conversions operate in "split view mode"
where the maintainer's branch(es) are left alone.
Indeed you can try dgit for one upload and go back to using dput for
your next upload. You can even have a packaging team some of whose
members use dgit push and some don't. [3]
> Contrariwise, on the assumption we are instead talking about a
> `conversion to a Git tree' that would seamlessly let DGit support the
> ongoing workflow of Debian packaging in a repository separate from any
> upstream 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.
>
> While acknowledging you are under no obligation to implement features
> demanded by others, I'll point out that for as long as DGit lacks
> support for that workflow, you won't get much user feedback from people
> whose Debian packages need that workflow and therefore are not
> knowledgeable DGit users.
Are you a user who uses this workflow, and who would strongly consider
using dgit if this git tree format were properly supported ?
If so then I would like to talk to you more.
Particular questions I would like to ask are:
* Do you have the upstream source code available in git form ?
If you do then it should be used, since that is much better
than a tarball import. How might it be found, automatically ?
* If so, is the .orig tarball you are using exactly identical to
what you have in git ?
Ideally, CC the answers to #903392 :-).
(If we can't get the upstream source in git form then the the result,
for a user of `dgit clone', would be significantly less useful: it
would still involve tarball imports. The real benefits emerge when
the user can not just `git grep' the whole thing, but get a useful
`git log' that shows something other than "imported upstream 1.2.3",
can `git merge' some other upstream code, etc.)
> So for as long as that persists, it will take special consious effort to
> remember that there's a class of Debian package maintainers who would
> like to become knowledgeable about DGit but can't yet; that the current
> DGit user base is not representative of that class of potential user.
>
> I trust you already know this, but it bears explicit expression from
> time to time :-)
I'm aware of this, thanks. So far I have gained the impression that
the kind of people who are using packaging-only git trees tend to be
very conservative, and very comfortable with .dsc/tarball/patch/quilt
based tools, and not really convinced of the usefulness of git.
I have even experienced what feels to me like significant hostility.
If I am wrong and there are more users to be had by implementing this
feature then I will definitely consider giving it a higher priority.
BTW, dgit is capitalised thus.
Regards,
Ian.
[1] The dgit view history for an upload is arranged so that it is ff
from the converted version of the previous one upload; and it has the
maintainer's history as an ancestor (which makes git log etc. work).
[2] The git objects representing the conversions are retained in the
maintainer's git tree, but they are reachable there only from
dgit-specific refs. If the maintainer deletes those refs nothing will
go wrong, but if those objects were garbage collected a future dgit
push would end up downloading them again from the dgit git server,
which is not desirable.
[3] If you are *not* using the split view feature, your dgit push will
usuall involve stitching the dgit history (with perhaps a .dsc import
or two) into your branch. If you then go back to using dput that will
remain harmlessly in your history. This is one reason why
#926640 want split brain mode with --quilt={linear,...}
would be nice to fix.
>
> --
> \ “Our task must be to free ourselves from our prison by widening |
> `\ our circle of compassion to embrace all humanity and the whole |
> _o__) of nature in its beauty.” —Albert Einstein |
> Ben Finney
>
--
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: